That’s awesome. I wonder how easy would it be to code an easy service that generates a different card for every subscriptions. No more hassle to cancel this gym membership!
Be careful of the "cancel this gym membership" approach. Gyms in particular have a reputation for sending you to collections if you try to end your contract that way, as the contracts generally specify a specific way you have to end the plan.
No merchant agreement prohibits the merchant from pursuing the purchaser through collections or small claims court if a chargeback occurs or the charge is declined (in the case of a recurring subscription).
That may be a bad idea — you have entered into a contract, one that likely doesn't account for that sort of "cancellation" and so gyms could legally keep charging you, consider the account delinquent for awhile, then close it and sell that debt to a collection agency. On the other hand 24h fitness auto-canceled my membership when I didn't go for a little while, so at least some have some kind of incentive to not have people hate them.
you have entered into a contract, one that likely doesn't account for that sort of "cancellation" and so gyms could legally keep charging you, consider the account delinquent for awhile, then close it and sell that debt to a collection agency.
My wife and I own two gyms, and no matter how easy we try to make it for people to cancel - you can literally email us at 9pm the day before you get charged and if we see it we'll cancel it - people still treat the charge back functionality like an "oops didn't mean it lol" thing.
Huge gyms like Gold's or PF have these oppressive terms because they have to, otherwise at their scale they'd be getting hit with multiple charge backs every day at every location. We have less than 300 members between our two facilities and still see one every month or two, mostly from people who don't understand what they're actually for - fraud, subpar delivery of whatever you purchased, or not receiving whatever you purchased - not as an easy refund button so you don't need to take 10 seconds to write an email.
The most we can hope to get out of fighting a charge back is the money back (less the additional charge back review fee which is $15-30 depending on merchant) and a very high likelihood of a 1-star Google and/or Facebook review. And that's best case scenario when the merchant is willing to side with us instead of the customer, which is why we're forced to now have contracts detailing cancellation policies. It will never happen, but I really wish consumers had to pay the charge back fees when they use the feature fraudulently like many do.
Just got API access with privacy.com. This space is ready for lift off IMO. Long in the works and long overdue. Good luck to everyone involved in creating, and god speed to those integrating.
Sign up for Privacy.com seems to be only in the app or with the extension, but after you sign up, you can sign in just in the browser and view your virtual cards. (I hope this comment will soon be outdated - a fix for that would be nice.)
It's ironic that they are called "privacy", when they are really just monopolizing your service usage information. Instead of Visa knowing exactly what services I use, now "privacy" does.
I think there's an additional security aspect to this. A big company has their credit card processing system breached? Cancel the card for that vendor, and you don't have to worry about updating all your bills/autodebit.
How is the balance of the card established? Is it just paid from a connected bank account similar to a chargeback after a payout has been already paid into a bank account?
We're starting out in the U.S., but have a number of other markets in-flight. Please let us know about your use case on the invite form (https://stripe.com/issuing) — that'll help us prioritize where to go next :)
I have reached out, just now, please begin the discussions with us asap because we are in the middle of going with Emburse and would consider this instead.
Emburse are great! They provide far more in the way of user a user experience to set controls, manage budgets, etc. We'd highly encourage going with them! (Stripe Issuing is an API-first product -- if you want to build software like Emburse, we would be more suitable.)
If I use my normal VISA card at a retailer they pay an interchange fee right?
If I create a physical card through stripe, and I use that card at a retailer does the retailer still pay a interchange fee? If so who does that go to? How does that system work?
Normal interchange would apply to the merchant but for debit cards it's pretty small. Interchange accrues to the issuer which in this case appears to be Stripe (and/or its issuing partner).
Hey Lachyg - it seems that this is designed party to allow companies to issue cards on behalf of their customers. Is there a way to draw the funds directly from the customer's checking account? Potentially being on the hook for a charge if something goes funky with the customer seems like a big risk for the Stripe Issuing user.
Also, my understanding of payments is that the issuing bank is a big recipient of the fees that merchants pay. (This is of course what makes rewards cards possible.) In this case, Stripe is the issuing bank, so presumably gets a big chunk of the fees. Are there plans to share that with the Stripe Issuing developer? (For example, let's say I plan to launch the Zip Line Adventure Bonus Card - ZLABC. For every dollar a ZLABC customer spends, they get a point, and after 10,000 points I pay for them to go on a zip line adventure at a partner park. As a normal bank, I could fund that because I get somewhere in the 1%-2% of each transaction that my customer spends. In this case, Stripe gets it, but if Stripe shares some of that with me, I could find my wacky wimpy rewards card idea.)
Glad to hear you like it! We’re looking for a range of customers who have various use cases and experience levels with issuing before we’re ready to make this available more broadly. (Sorry I don’t have much more in the way of specifics to share here, we’ll do our best to get back to you quickly.)
I actually think they might just be proving how easy it really is... compared to the longtime incumbents who do their best to make it look hard (or do it the hard way), and charge appropriately. Which doesn't take anything away from the accomplishment.
They hate it when they have to change their card number and have to update it on a ton of places. If that ton of places have their own numbers, you don't have to update them all when you have to kill one number.
Tokenized payments (Apple Pay, Google Pay) which are supported by many card providers work by generating a new card number when you add it to the device.
Congrats to the teams at Stripe for getting this out. This opens up a lot of potential for innovation with these kinds of cards. Well done!
Stripe and Twillio lower barriers to entry with products like this. This eliminates a powerful moat that other companies have built. Starting a digital bank or expense report software like Divvy are now much easier. What companies will be at greater risk because this is now an API?
Not sure if you know, but Bank of America, Paypal and others have tried this a long time ago (in Internet years). They all abandoned this idea, iirc because of the upkeep costs (?) and massive amount of fraudulent use.
I suspect the key fraud deterrent is that funds must be available in Stripe in order for the card to accept the transaction. In other words, if I issue a card via Stripe and you attempt to use it fraudulently, I'm on the hook for the transaction either way.
Cue a plethora of startups popping up where the main business model involves harvesting the transaction data via such cards. Probably most interesting for shopping sites since it gives you insight into all the transactions made with competitors (only just realized that that's probably why Amazon issues credit cards).
Also why uber did their own credit card, gotta imagine. Using that data for where people are going and where they are ordering from (UberEats) has got to be extremely valuable.
So the question then begs. Is this the beginnings of a digital bank?
Will they start to do things like:
- Virtual Accounts / Ledger support.
- Micro Loans.
There doesn't seem to be a digital bank that does end to end payments in the US, that businesses can plug into with an API and have everything taken care of.
There is Railsbank[0], yet they are located in the UK and US support may be in Q4 this year. But they aren't an acquirer.
p.s if anyone does know of an end to end fintech service provider for the US. Let me know. All of the ones that I have found, unfortunately are EU only.
Thank you for posting the first link. I know BBVA are behind many companies such as Simple, Azlo, Holvi; either as investing in them or buying them outright.
But I hadn't come across that link when searching on google. I am highly appreciative! I'll send them an email in the morning.
Any chance Stripe lifts some restrictions on prohibited businesses soon? Virtual cards can be particularly useful in travel, but that use case on Stripe has long been considered prohibited:
https://stripe.com/us/prohibited-businesses
Are these credit or debit cards? Asking because I've previously had issues with virtual debit cards where merchants "force posted" transactions through.
That doesn't tell you anything about which network and rules the transactions go through on, in theory they can process it as credit even if they require it to be prefunded
Have only spent 10 minutes skimming through various docs.
Seems like it's upto the businesses to treat an issued card as debit or credit. I can even see use cases for overdraft.
Below is a snippet from their doc[1]
> Any use of an issued card that results in funds entering or leaving your Stripe account
Here's what I've understood so far.
1. Businesses create, maintain and own customer accounts. It's upto the businesses to figure out how to get money from the customers. Could be prefunded (i.e., debit card) or postpaid (i.e., credit card).
2. Said business then creates cards and associates them with the above customer accounts and issues them that card.
3. Customers are now enabled to use those card wherever credit/debit cards are accepted.
4. Businesses need to maintain balance with Stripe. Stripe deducts from this account upon successful authorisation.
5. Now as I've mentioned in #1 it's upto the business to figure out a way to charge the customer.
Money movement is happening in two steps.
1. Business account -> Merchant (via stripe).
2. Consumer -> Business (Stripe isn't involved here).
Whether #2 happens before or after determines if the card is a debit card or credit card respectively.
So, what Stripe has done essentially is connect accounts holding money with rest of the world. I.e., anyone can now become a bank, in a sense.
In my previous job my team worked with a similar third party provider to launch a virtual card product[2]. But what Stripe has done is game changing.
About the network they are quite clear right upfront.
> "Stripe Issuing is certified directly with all major card networks as an issuing processor, which ensures reliability and rapid feature releases"
As for the rules I guess the business needs needs to adhere to the rules of whichever country it operates out of. Don't see Stripe helping there. They have built the roads, it's upto the driver to procure valid license.
That literally gives zero information about whether it's processed as debit or credit. There are very different sets of rules depending on which one it is.
The technology we've built is agnostic to debit or credit -- it really depends on your use case. That said, force posts (or transactions cleared without an underlying authorization) can happen on any card type.
For what it's worth, we have an API to initiate disputes (which you would be able to on a transaction initiated without a valid authorization) which you could use to recoup funds.
Like it seems like everything Monzo has done as easy to replicate (not to do, im sure a lot of time and effort went into the guys at Stripe making this).
Not really. We make it easy for institutions like Monzo to issue and manage cards, but I imagine that's just a fraction of what they've needed to build to run a regulated bank, service their customers, etc etc.
It's not really the same. Monzo's a bank capitalising somewhat on UK Open Banking legislation[1] and the fact that traditional banks are very slow to move with the times. It's not a SaaS product, they're likely one of if not the first movers in the market. There are competitors (Monese, Tide for business, N26 is coming at some point soon). UK fintech is pretty vibrant.
You would hope that Monzo is easy to replicate well because that means you have more modern banks to choose from.
Would these cards work with more vendors than Privacy.com cards? Many web services, for example, reject Privacy cards because they show up as "prepaid" cards.
This is my question too. I want to know how these generated Stripe cards are classified by the major credit card processors, because generated cards often get declined if determined to be temporary/gift cards.
It depends on the type of card issued/use case, but prepaid cards issued through Stripe Issuing would still have that same challenge :-( We agree it's a pretty sub-optimal user experience.
(That said, given many of these businesses may be on Stripe, we should have more ability to work with them to improve the experience for customers...)
Do you have any timeline on when you'll start offering your services in Poland? I'm always amazed at the quality of your offering, but always sad that I can't use them.
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.
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).
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'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.
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.
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.
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.
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.
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. :(
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.
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.
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.
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.
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.
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.
> 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.
Google (and likely others) tend to block these types of virtual cards, similar to how they block Twilio generated phone numbers from being used in registration.
How do you ensure the card numbers will be respected?
Last time I asked this in another thread I got one response that indicated it may be to prevent card number inception, of sorts...
I believe Visa and MasterCard merchant agreements prohibit retailers from denying specific cards. That's why AMC theaters can't block MoviePass customers from purchasing tickets, because they are regular MasterCard credit cards.
This looks really intriguing. I wish it provided some clues on pricing (e.g., order of magnitude numbers on what it will cost to issue a card, monthly fees per card?). That would help one better determine what kinds of business models could use it.
Almost - Marqeta’s offering is more advanced and mature. I don’t doubt that this is causing some waves there though. Stripe is now a very serious competitor of theirs.
Marqeta is US only currently; they say end of the year maybe EU. They have not been very helpful so far either; when talking with them, it feels like talking to a huge, stodgy bank.
As someone who's been integrating with a major card provider's virtual card SOAP API, this. This looks like magic in comparison, shaving off pounds of SOAP bloat.
216 comments
[ 1225 ms ] story [ 6310 ms ] threadhttps://news.ycombinator.com/item?id=17468176
This happens. A LOT.
Huge gyms like Gold's or PF have these oppressive terms because they have to, otherwise at their scale they'd be getting hit with multiple charge backs every day at every location. We have less than 300 members between our two facilities and still see one every month or two, mostly from people who don't understand what they're actually for - fraud, subpar delivery of whatever you purchased, or not receiving whatever you purchased - not as an easy refund button so you don't need to take 10 seconds to write an email.
The most we can hope to get out of fighting a charge back is the money back (less the additional charge back review fee which is $15-30 depending on merchant) and a very high likelihood of a 1-star Google and/or Facebook review. And that's best case scenario when the merchant is willing to side with us instead of the customer, which is why we're forced to now have contracts detailing cancellation policies. It will never happen, but I really wish consumers had to pay the charge back fees when they use the feature fraudulently like many do.
They have virtual cards as well as a disposable one that changes number every time you use it online.
The cards draw from a Stripe balance, which can be funded from a connected bank account (or ordinary Stripe charges).
Cards draw from a Stripe balance (which is funded by payments that go through Stripe (or top-ups).)
Looked through the docs and meets the same needs that Emburse meets.
If I create a physical card through stripe, and I use that card at a retailer does the retailer still pay a interchange fee? If so who does that go to? How does that system work?
Also, my understanding of payments is that the issuing bank is a big recipient of the fees that merchants pay. (This is of course what makes rewards cards possible.) In this case, Stripe is the issuing bank, so presumably gets a big chunk of the fees. Are there plans to share that with the Stripe Issuing developer? (For example, let's say I plan to launch the Zip Line Adventure Bonus Card - ZLABC. For every dollar a ZLABC customer spends, they get a point, and after 10,000 points I pay for them to go on a zip line adventure at a partner park. As a normal bank, I could fund that because I get somewhere in the 1%-2% of each transaction that my customer spends. In this case, Stripe gets it, but if Stripe shares some of that with me, I could find my wacky wimpy rewards card idea.)
It would make the CC numbers from database leaks a less valuable target since users could easily compartmentalize for every transaction.
Stripe and Twillio lower barriers to entry with products like this. This eliminates a powerful moat that other companies have built. Starting a digital bank or expense report software like Divvy are now much easier. What companies will be at greater risk because this is now an API?
It's annoying because it pops out multiples modals on my desktop (and complaning my HMD is not connected) and my mouse cursor starts to shutter....
Latest Steam Stable with Steam VR beta module on Windows 10 x64 Pro 1803
Edit: formatting
Edit: found a way to disable: dom.vr.openvr.enabled in about:config (why does it trigger openvr?)
Will they start to do things like:
- Virtual Accounts / Ledger support.
- Micro Loans.
There doesn't seem to be a digital bank that does end to end payments in the US, that businesses can plug into with an API and have everything taken care of.
There is Railsbank[0], yet they are located in the UK and US support may be in Q4 this year. But they aren't an acquirer.
This is a very interesting development for sure!
[0]: https://www.railsbank.com/
p.s if anyone does know of an end to end fintech service provider for the US. Let me know. All of the ones that I have found, unfortunately are EU only.
https://openplatformbbva.com
https://synapsefi.com
https://www.marqeta.com
But I hadn't come across that link when searching on google. I am highly appreciative! I'll send them an email in the morning.
Any chance Stripe lifts some restrictions on prohibited businesses soon? Virtual cards can be particularly useful in travel, but that use case on Stripe has long been considered prohibited: https://stripe.com/us/prohibited-businesses
Also, any chance for custom prints on the cards?
Seems like it's upto the businesses to treat an issued card as debit or credit. I can even see use cases for overdraft.
Below is a snippet from their doc[1]
> Any use of an issued card that results in funds entering or leaving your Stripe account
Here's what I've understood so far.
1. Businesses create, maintain and own customer accounts. It's upto the businesses to figure out how to get money from the customers. Could be prefunded (i.e., debit card) or postpaid (i.e., credit card).
2. Said business then creates cards and associates them with the above customer accounts and issues them that card.
3. Customers are now enabled to use those card wherever credit/debit cards are accepted.
4. Businesses need to maintain balance with Stripe. Stripe deducts from this account upon successful authorisation.
5. Now as I've mentioned in #1 it's upto the business to figure out a way to charge the customer.
Money movement is happening in two steps.
1. Business account -> Merchant (via stripe).
2. Consumer -> Business (Stripe isn't involved here).
Whether #2 happens before or after determines if the card is a debit card or credit card respectively.
So, what Stripe has done essentially is connect accounts holding money with rest of the world. I.e., anyone can now become a bank, in a sense.
In my previous job my team worked with a similar third party provider to launch a virtual card product[2]. But what Stripe has done is game changing.
[1] https://stripe.com/docs/issuing/transactions [2] https://www.freecharge.in/mobile/freecharge-go
Edit: Minor correction.
> "Stripe Issuing is certified directly with all major card networks as an issuing processor, which ensures reliability and rapid feature releases"
As for the rules I guess the business needs needs to adhere to the rules of whichever country it operates out of. Don't see Stripe helping there. They have built the roads, it's upto the driver to procure valid license.
The technology we've built is agnostic to debit or credit -- it really depends on your use case. That said, force posts (or transactions cleared without an underlying authorization) can happen on any card type.
For what it's worth, we have an API to initiate disputes (which you would be able to on a transaction initiated without a valid authorization) which you could use to recoup funds.
In my observation debit issuers make it much harder to do chargebacks.
https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules... here's a 1031 page document with all the technical rules from Visa. You'll note there are entirely different sections for debit and credit.
Like it seems like everything Monzo has done as easy to replicate (not to do, im sure a lot of time and effort went into the guys at Stripe making this).
Not really. We make it easy for institutions like Monzo to issue and manage cards, but I imagine that's just a fraction of what they've needed to build to run a regulated bank, service their customers, etc etc.
You would hope that Monzo is easy to replicate well because that means you have more modern banks to choose from.
[1] https://www.openbanking.org.uk
(That said, given many of these businesses may be on Stripe, we should have more ability to work with them to improve the experience for customers...)
Do you have any timeline on when you'll start offering your services in Poland? I'm always amazed at the quality of your offering, but always sad that I can't use them.
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.
So like Shipt or Postmates?
link: https://privacy.com
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.
* 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.
I do wonder if I'm getting flagged as a higher fraud risk when I use it, though.
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. :(
I have a friend at CapOne, I’ll ask tomorrow.
However I would suggest a temporary card that only lasts for 2 transactions.
- the authorization charge (e.g. $1 on amazon.com) [1]
- the actual amount of the purchase
Too many times I have been caught out by the authorization charge, only to have the actual purchase fail.
[1] https://aws.amazon.com/premiumsupport/knowledge-center/aws-a...
https://www.capitalone.com/applications/eno/virtualnumbers/
Looks like a great product and props to you and your team for shipping this.
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.
You could pre-approve the transaction and then confirm it within 2 sec though.
It adds a step during checkout where you are redirected to your bank/card issuers page to answer some security questions.
[0]https://vivokey.com/learn-more.html
Btw is this similar to Marqeta‘s JIT solution?
Does this work in all banking jurisdictions?
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.
https://galileoprocessing.com/ https://www.pexcard.com/
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.
How do you ensure the card numbers will be respected?
Last time I asked this in another thread I got one response that indicated it may be to prevent card number inception, of sorts...
https://news.ycombinator.com/item?id=17524398