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.
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.
I don't see anything on the landing page either, but this text from the "overview" page of the documentation seems to imply debit:
> When an issued card is used to make a purchase, an authorization request is created. If approved, the authorized amount is held in reserve from your account balance. [...] The merchant then captures (clears) the authorization, at which point a transaction is created and the held funds are deducted from your account.
This implies debit as the underlying mechanism for completing the transaction, however one could presumably build a credit-based business using these cards. If XYZ company issues a Stripe card under a credit model, then XYZ company would be footing the bill using their Stripe balance, and the cardholder would then have a credit balance with XYZ company.
I think they were referring to the little card animation on the side, that shows a card with Visa debit at some point. (Note sure if that also answers backend issuer. There's also one with Mastercard in the animation.)
Mostly, as a user, the main thing that I'm looking at is interchange revenue sharing (the main thing that makes a difference). This can vary for personal and business cards and can be a non-trivial revenue source. If this is not competitive, having the well-known Stripe integration convenience doesn't go that far. I'd rather suck it up and work with an old-school CC vendor if this means the company gets a better interchange rev-share.
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.
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.
Setting the balance or editing it (could find nothing on it, maybe it was by invite)
Are the funds reduced from your income? Guess there will be API's to move funds between acceptance and issuing
Webhook on the settled amount of every swipe (for several MCC's this changes considerably)
I see active/inactive which block the card, maybe a call to disable/enable transactions will help
Requesting Stripe to considering getting the CVV/CVC as a separate GET call for security reasons
a lambda'esque authorization code editor with custom logic rather than setting mcc rules may open up more use cases
And Stripe - please ping me when you launch this in India or start issuing with an international BIN :D For anyone looking for a service like this in India, checkout
https://platformdocs.bon.pe/
It also has an API to create "paylater" cards. In which case during the authorization of every swipe - an auction takes place between lenders to decide who gets to fund that transaction based on a custom credit score, mcc, and interest rate bids for that mcc. Bon works with a bunch of gig economies here already.
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.
Are CC numbers always unique? Or can there be multiple people with the same number but different expiry codes (or others).
I always wondered if we'd run out of cc numbers. 10^16 is a big number, but take out the checksums and unused blocks I'd guess we're down to only a few thousand per person.
I don't think that refutes OP's point. 10^12 is not that much, actually. That would mean that everyone in the world today gets only ~100 numbers (not even including offspring situations).
This is per issuer, so each issuer has a trillion card numbers at their disposal. Plus, the population that is eligible for credit doesn't equal total population of the planet.
There may be only a handful that are well known, but that doesn't mean that there aren't more possible issuer numbers available. The first six digits make up the issuer identifier, so there are 10^6 possible issuers.
Sure, it's not ipv6 level address space (2^128), but ~10,000,000,000,000,000 possible card numbers seems like it should last many lifetimes, especially if you consider that card numbers could be recycled/reassigned, and if we ever approached the point where running out of numbers was within imagination, we would come up with a new scheme that allowed for a few new digits. My guess is the credit card itself as a concept will be long gone before the numbers are all used up.
If the first 6 digits make up the issuer, since there are only 10 remaining digits, wouldn't that mean there are only 10^10 numbers per issuer? Where's the other factor of 100 coming from (IIRC, OP said there were 10^12)?
> My guess is the credit card itself as a concept will be long gone before the numbers are all used up.
I agree. Products like "privacy.com" hint that we could be approaching a "new number per purchase" meta. Even in that edge-case, if one million issuers get to have 10 billion numbers each, that would leave tens of concurrent purchases per person per issuer for an issuer with a billion users. A monopoly-level media site that lets you open a paid-subscription to multiple people could easily end up needing tens of concurrent cards per user. It seems like issuer-to-issuer number recycling would be required for sure.
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.
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...)
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.
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.
I've had pretty bad experiences with Stripe in the past, which is why I switched to Braintree. Stripe has abysmal support for square use-cases that don't fit their circular criteria.
Nevertheless, this is one development that makes me interested in Stripe again. I'm looking forward to using this at some point in the future when they open this up out of friends-frist mode.
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.
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.
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.
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!
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.
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.
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.)
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.
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).
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.
Excellent, but invite only and I couldn't change my country in the country dropdown so not sure if I will ever get an invite...
Does anyone knows an easily accessable version of this product for the UK and/or EU? So far either it's not available in the EU or you have to jump through a lot of hoops with the existing providers I tried to even make a simply PoC. Not even for rollout but an entirely, no risk to them, PoC. I am looking for a B2B solution; I am not a consumer looking for virtual cards; I need this for my clients.
Anyone knows any API that will let me do a PoC so I can test it out in the real world? I have clients looking for this kind of solution, but haven't been able to find anything that I can even check if it works at all.
I would love an app that would allow me to dynamically generate business credit cards for use with paying stuff online. Whenever one of my 20+ recurring payments get compromised, I then have to spend half a day going through all my recurring payments providers and re-issuing with a new card. I would much rather have one card for each one.
There was a startup working on this but unfortunately they closed down before they launched. I still think this is a really interesting idea and someone should implement it. I suppose you could just use the Stripe API for most of the heavy lifting. I would actually start this company, I think it's that good of an idea, but unfortunately I'm little busy at the moment.
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.
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.
What's in it for them? Where's the business model for Stripe?
I find it extremely annoying that companies - any company - just can't be totally upfront about this.
"We earn money from this by you having to fund these cards using an account you must have with us, where we get interests. Also by the merchants where the card is used, which have to pay from 1,5% to 3,5% in processing fees" etc.
Shouldn't be too hard - I guess they already have this in some PowerPoint laying around.
Having worked in the payment industry I'm not "too" impressed they did this from a technical standpoint (I've seen small startups do similar) but to make it easily available via Stripe's awesome APIs is pretty great.
I would love to see details on pricing. How much a card costs, how much a virtual number costs, how if at all issuers can monetize (i.e. do I get a cut of the transaction fees?), etc.
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
Some more insight into how cards are fulfilled would be nice, virtual I get but how are we going to be able to customize card design (kind of don't want an ugly card for my users), since there are many card types and will he card support NFC? This seems very early and lots of stuff needs to be thought out, for our use case we need details before evaluating this.
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.
I wonder if it would be feasible to use this as personal service, ie issue a card for each online shop or service I use and generate myself the bills and reports for that... Though I don't think it's meant to be ~~ab~~used for personal gain...
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?
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.)
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).
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.)
Are these credit or debit cards? Asking because I've previously had issues with virtual debit cards where merchants "force posted" transactions through.
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.
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
This is pretty cool. But I would like to know more about the penalty interest rate and the credit card bill payment (which the docs completely didn't mention)
As I understand it, the debits come from an existing stripe balance attached to a bank account. You can’t take on a negative balance so there’s no interest rate or bill to pay (outside of the fees and whatnot associated with using the API, top ups, etc)
From the perspective of the business issuing the cards, basically. But, from the perspective of the customers of _that_ business, it depends on how they set up the rules.
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 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 :)