This is really impressive, like the rest of the Stripe API! Although many people here are asking about creating virtual banks and issuing cards to customers, it appears that the intended audience of this API is a business that has a Stripe account, that wants to be able to issue cards to employees/trusted officials that charge against that single Stripe account. There is no mention of issuing cards to external customers that link against their own, external accounts, right?
I ask because the webhook that Stripe fires at purchase time is fantastic, and you could build some great things if their API gave you access to authorized real-time purchase data for customers. This doesn't appear to facilitate that though.
Does anyone know of an API that would allow a Credit Card user the ability to grant real-time webhooks to a 3rd party as they swipe their card? The closest I've ever found would be setting up spending email spending alerts (that certain banks allow), and then forwarding the emails to said 3rd party. It's clunky, and would only work with a few banks. Something like this issuing API would work if Stripe allowed you to issue a card that was linked to a customer's existing card/account. They'd basically be saying, "If I swipe _this_ card that you sent me, I'm agreeing to let you get notified." The other way I've considered would involve creating your own bank and issuing your own cards, but that's real work on both the developer and the customer's part :)
We've been primarily focused to date on companies where issuing cards is core to providing their business to customers, for example a startup that provides expensing customers, or a platform that needs to purchase goods in the real world. We're less focused on a business just using it for their own expensing (as we don't have receipt upload functionality, etc).
To your two other questions though:
(1) Could users approve things in real time? Sort of. We provide the ability (as you noticed) through API, but it needs to be responded to in < 2s, which means it's not possible for a human to be in the flow.
(2) Could this be linked to an external bank account? Again, sort of. To get in the weeds: as soon as we approve an authorization, we're on the hook for those funds. A debit to an external balance (or bank account) may fail and Stripe would be on the line. This is why we typically require funds to be in a Stripe account prior to purchases taking place.
As a credit card customer it would be nice to be able to generate one or more temporary cards (physical or not), which are authorized for one transaction only, but are otherwise identical to my main card. That way I can use it with a merchant I simply don’t trust to have their act together, then safely toss it in the trash.
I used to use this pretty thoroughly but a few issues have caused me to stop altogether now:
* Flash app means that in newer versions of Android (edit: 6+ IME), even with an old Adobe Flash for Android apk loaded and with Firefox, the functionality no longer works in mobile (input functionality is broken.)
* Cards used for time-limited recurring expenses (subscriptions that I intend to end in 1 year, for example) would arbitrarily fail transactions resulting in hassle. Since each number was locked to the processor who requested the first transaction, I suppose one reason this happened was if a business switched processors mid-stream.
I have always wondered why no one has created a nice mobile solution for this very useful feature. It seems that credit cards want each customer to just use one number and trust that their risk department will stop data leaks - seems like a bad solution.
They're sort of an intelligence network for payment processors. Took a few days and it worked again, but just be aware that having a new credit card every payment might put you in a higher risk bucket.
I've been using products that facilitated this for the past 10 years and one has yet to stick.
Paypal had a firefox extension that did this about 10 years ago.
https://getfinal.com/ was fantastic and I used it for about 2 years. I was one of the first 700 applicants. It worked exactly as you described and you could even set dollar limits for monthly recurring charges. They folded earlier this year and I was sad to see my CC cancelled. :(
Just wanted to say I've used them and they're great. You can set limits on the virtual card. As well as have them lock to only one vendor. So as soon as the sale goes through no other vendors can charge the card.
Have you looked into the existing options? Citi and Bank of America for example support virtual card numbers (virtual account numbers and ShopSafe, respectively).
Ah, yes, the UI (Flash-based in the cases I mentioned!) is definitely clunky, so it's not surprising Capital One's is similar. They also tend to hide the feature a little bit for some reason; it's not prominently displayed. But otherwise it's there and nevertheless usable if you can find it. If you need it on literally a daily basis, though, it might not be smooth enough to be comfortable.
A few banks provide a system like this. I'm aware of at least Bank of America and Citi.
Bank of America calls it "ShopSafe"; you can generate a number for one-time or recurring payment with an associated limit and expiration date.
Citi calls it Virtual Account Numbers. Theirs don't have a limit by default (but you can create one that does).
Unfortunately, both systems use archaic Flash applets to generate and manage the numbers... I hate the Citi one in particular because it has sound effects when you press buttons.
I've wanted something like this for a long time as well. The ability to generate and discard one-off card numbers. Much less worry about those card numbers leaking, unauthorized transactions, etc.
Entropay.com is great - I use it for sites that really don't want my Australian dollars (normally this is enough for me to never buy from them, but sometimes I really do need the product). The cards are "American", but appear to be issued somewhere in the EU - I've had the number rejected by someone, maybe Sling?
I do wonder if I'm getting flagged as a higher fraud risk when I use it, though.
Regarding 2), can Stripe Connect be used with Issuing? If each user of a Connect app just had their own Stripe account with their own balance, that sounds a lot simpler (for the developer).
That's amazing. I could imagine a personal web app where you set some sort of a personal spending limit and have to pre-approve transactions over that limit.
Hopefully increasing the response time to > 2s (whether it's settable in the API or just has a longer timeout) is on the roadmap, I can think of lots of future use cases where you would want a human in the loop on authorizations.
Looks like a great product and props to you and your team for shipping this.
That's not possible. Transactions need to be approved at the POS within a reasonable amount of time. Waiting for a human is to respond is not reasonable.
You could pre-approve the transaction and then confirm it within 2 sec though.
I can also imagine of lots of future, intensely frustrating use cases where a user scans their card in a line at a point-of-sale, or is waiting on a "Confirming purchase, please wait" page on a website while your human in the loop puts this approval on hold for a few minutes until your cell phone finally rings.
Currently, human-in-the-loop approvals do happen, but they happen long after the purchase goes through - ever gotten a call from your bank's card services department as you were leaving a gas station on a road trip? Much more convenient for the common use case where the human approves the transaction than the rare cases when the bank is on the hook for the stolen gas.
Since this is an API, that means you just build this into your app. You could initially decline the transaction, send a push alert to the user's app notifying them that the transaction is in review, then update them on that status when approved/declined. At that point the card can be run again and approved if that was the decision. You could even allow a pre-request through the app, when when approved would enable your user's card for the purchase. The possibilities are endless.
> Does anyone know of an API that would allow a Credit Card user the ability to grant real-time webhooks to a 3rd party as they swipe their card?
Galileo and Pex already support basically the same stuff as Stripe Issuing. It's nice to have this option within the Stripe ecosystem though. If you use stripe and an existing 3rd part to do this there are bank transfers involved to get funds from one place to the other.
I've been a mint user and YNAB customer with all bank accounts linked, but neither turned out to capture me. I've had some interesting ideas and conversations about budgeting and influencing purchase habits, so I looked into getting access to a real-time transaction log.
I started on your same path, email alerts per bank, but then found it was possible to jump up a level to the payment network using Visa Purchase Alerts. I signed up the alerts to an automated inbox that parses the content for the transaction name, location, amount, and last4. It's working with the first four credit cards I have tried, and I receive the notice generally within seconds.
This works out well for a product targeting U.S. credit card debt. Hopefully MasterCard will follow suit, which is then potentially 100% market coverage, if you can convince a user to signup with an email address of your service.
I ask because the webhook that Stripe fires at purchase time is fantastic, and you could build some great things if their API gave you access to authorized real-time purchase data for customers. This doesn't appear to facilitate that though.
Does anyone know of an API that would allow a Credit Card user the ability to grant real-time webhooks to a 3rd party as they swipe their card? The closest I've ever found would be setting up spending email spending alerts (that certain banks allow), and then forwarding the emails to said 3rd party. It's clunky, and would only work with a few banks. Something like this issuing API would work if Stripe allowed you to issue a card that was linked to a customer's existing card/account. They'd basically be saying, "If I swipe _this_ card that you sent me, I'm agreeing to let you get notified." The other way I've considered would involve creating your own bank and issuing your own cards, but that's real work on both the developer and the customer's part :)