Generally, and on Citi for sure, you can electronically schedule the payment to be authorized on the 20th, and though the money is taken out a few days later, there is not a late charge assessed. Other banks are different - I recall that MBNA would charge you a late fee if you attempted to make an online payment on the due date, if you didn’t pay their extortion (expedite) fee (though it may have been possible to schedule it for the exact day ahead of time - MBNA deserved it’s own pitting for many things). It depends on how their particular system is set up, apparently some don’t do it automatically, and need outside intervention/entering.
Generally bank bill pay is just a check, and sometimes they send one large check to a vendor, aggregating their customer’s payments.
But this is a two-way street and it takes two to tango. Assuming amounts going from Paypal to banks is about equal to the amounts going the other way, why would both parties accept the delay? The float that benefits one party is a loss to the other and vice-versa.
I can’t believe I’m asking this but do you have a cite for your numbers? I’m fairly sure that the majority of online payments in the US are through the VISA/Mastercard interchange system. I would be very surprised by your 80% ACH stat.
Secondly, PayPal makes $0 dollars on “float”. Funds held in your “account” are actually held in a separate bank that provides you FDIC pass-through insurance on your behalf. PayPal cannot make “float” on funds in an account that is not theirs.
Lastly, online payments through the ACH network take that long due to all of the batches to process through: the institution initiating the payment–>their processor–>the federal reserve–>the receiving bank and then back again.
Interchange is instant because when the payment is “Authorized” there is an agreement that binds issuing banks to make good on those funds through VISA/MC compliance. There is no “authorization” in the ACH system and therefore any institution willing to make funds instantly available on an ACH transaction takes a large risk.
The 70% figure is what the big wigs at my company tell mere programmers like me. It could be out of date, inflated, or they may be defining the market in such a way that you or I wouldn’t recognize the validity of the figures. We’re doing about 120 million payments per month right now.
You are correct that the number of credit card payments far exceeds the number of what I’m calling online payments. The payments I’m talking about are payments from a consumer’s DDA or money market account to a payee. Individual credit card transactions are an entirely different thing. My company’s quarterly report states that we are processing about 120 million ACH transactions per month. We make lots of payments to credit card companies, but we have nothing to do with the payemtns processed by the credit card networks.
My mention of float and Paypal was simply a guess. It’s usually a good guess when a two-sided transaction takes longer than is operationaly necessary, but I will bow to your greater knowledge of Paypal’s working and agree that there must be some other reason for the slowness of those payments. It is possible, because the debit and credit are obviously happening separately, that the delay is simply to allow time to verify that the debit has worked before attempting the credit.
I recall once when I made a Paypal payment that exceeded the amount in my Paypal account by about $5. Although the time frame to make the main transfer was given as 2-3 (or 3-5?) days, the overdraft amount was done faster than a browser refresh. That shows me that the technology is not the limiting factor; it must be something else, and a deliberate slowdown. I just can’t figure out who benefits.
Musicat, almost any payment could be made instantly, but it is risky and expensive to do so. Technology is part of the reason. Databases which are optimized for quick and constant retrieval, like banking data that is available for viewing by millions of customers at once, is pretty much by definition not optimized for efficient real-time inserts and updates. In the ACH business, which my company is in, there is constant pressure from our bank customers to drive down costs and eliminate failed transactions. Batching the transactions is the best way to do this, and the vast majority of our transactions are done in batches. The technology to do instant payments definitely exists, but it is more costly per transaction and carries greater risk that one side of the transaction might fail. My company does thousands of instant transactions per day, and millions of batched ones. Our bank customers charge a premium for the instant payments, and most do the slow ones for no change to their customers.
PayPal is one of the institutions that does make some ACH transfers immediately available. Its the prime factor that enables their business model to be profitable.
Paypal also has a “backup funding source”, like a credit card, that they can use if your “check” bounces. That’s why they’re willing to release funds before they clear.
In the example I gave, the source of the funds for the “overdraft” and the main order was the same card, same bank, same account. But one went through in seconds, the other in several days. The one for $5 was instant, the one for $100 was several days. Makes no sense.
If you tell me that instant payments thru Internet sources are more expensive than delayed ones, the only reason I can see is policy. I can see no reason why the electronic functions are different in cost. The bytes transmitted do not know why how they are being used.
Musicat, I think I see the source of the confusion on this issue. When a customer goes online to pay a bill, the instruction to schedule the payment is made via a secure internet site. The payment itself has nothing to do with the internet. ACH transactions are processed via dedicated secure phone lines, not via the internet. So you deal with your online bill payment site via the internet, but after that, it all happens on much more secure, expensive lines.
So dedicated, secure phone lines take 3 days to send data that secure Internet sites do in milliseconds? Sounds like somebody needs to do some serious upgrades.
The trouble is, the somebody that needs technology upgrades is a very long list of retailers, cable companies, garbage collectors, newspapers, utilities, etc.
We in the Bill Payment industry would love to be able to do “instant” payments, but most companies that send you a bill don’t have that capability. We’re happy if they can accept ACH. And when you get a bill from your local garage down the street it’s likely the only way to pay that bill is to print a check and mail it to them.
I’m sorry it doesn’t make sense to you. The secure lines are very fast. I brought them up to try to differentiate between internet transactions and ACH transactions in general, to let you know that an electronic banking transaction and an internet secure-site purchase, for example, have very little to do with each other technologically. Advances in technology have not changed the fact that the most efficient and accurate way to update a large database with millions of transactions is in batches.
Both the source and target companies involved in my company’s electronic payments prefer the batch method. For instance, as Algernon noted, the local utility where you live does not want to receive an individual electronic payment from every customer they have. Most payees simply won’t accept individual electronic real-time payments at all. They will accept aggregated direct electronic transactions into their bank accounts with related transaction detail reports sent to them electronically. The source banks for our transactions prefer that we bombard them with debits in the middle of the night, rather than nibbling away at their customer accounts database during their busiest times.
I’m sorry I’m not able to make this any clearer. It figures. Finally a subject comes up on SDMB on which I’m an expert, and I can’t make myself clear.
It’s very simple. The technology exists for rapid money transfers. It has at least since the Internet became ubiquitous. It is not being used to full advantage by even the big players. I’m talking PayPal, Amazon, eBay, large banks, and credit card companies, not Mom & Pop garages.
Even if batch processing is preferred – and I maintain that such thinking is obsolete – it could be done in hourly batches instead of 3-day batches. But it’s not.
So to answer the OP – online payments take so long because the players choose to do it that way, not because the technology isn’t there to do it faster.
I understand what you are saying. My job is designing and building feeds between lots of companies. The one that I do control all sorts of insurance enrollment and other types of benefits for millions of people.
Sending things in real-time doesn’t work from a business perspective on either side so we tend to send files once a week in the middle of the night for processing. I think one thing people have trouble grasping is that there are very few processes that are truly automated. We have many teams of analysts on our side checking for problems every week, the vendor has teams on their side as well checking things, and there are almost always some errors that kick out of every process. We have time-lines every week for getting things sorted out including going over whole groups of exception reports. Those processes could not work in real-time. Just because there are big, powerful computers involved does not mean that they can operate autonomously.
However, just because the technology is there, doesn’t mean the applications have been written yet to take advantage of the technology. And just because it’s possible doesn’t mean it’s practical.
You might want to refrain from answering questions on subjects about which you have little information and lots of conjecture. I would be interested in reading a description of the existing technology for processing tens of millions of payments daily in real-time. There is a basic fact that I think you don’t understand about online payments. The internet has nothing to do with actually posting electronic payments. People can authorize payments via the internet. That is what happens when you “pay” a bill online. The actual payment is not made via the internet. It is made via secure phone lines by authorized ACH participants. The various players (the Federal Reserve, your bank, your payee) simply will not allow internet access to your money.
When you use your credit card to “pay” for something on the internet, you haven’t created an actual payment by that action. You have authorized a debit against your credit card. The merchant has an assurance of payment from the credit card network at that time, not the actual credit. You haven’t actually caused any money to move yet. Shagnasty has brought up one of the reasons that payment processors and banks build a lead time into the scheduling of online payments. When my company processes a batch file of several million debit transactions (we process more payments in a day than Paypal does in a quarter), a percentage of the debits fail. There are insufficient funds, the account has been closed or suspended, there are lots of reasons. Most of the debits are successfully processed. The information from the successful ones goes into another set of batch files for credit processing. The failed debits are worked on by actual people, and some of them are processed in later batches.
I have tried to share a bit of information here about how this stuff works. Musicat, you seem remarkably resistant to taking in information. I understand that you think you know something about the technology involved, but you clearly do not. You might want to take a look at what Wikipedia has to say about it and follow some of the external links at the bottom of the article to learn a bit about ACH payments.
