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.
However I would suggest a temporary card that only lasts for 2 transactions.
- the authorization charge (e.g. $1 on amazon.com) 
- 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.
* 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.
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.
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 do wonder if I'm getting flagged as a higher fraud risk when I use it, though.
So like Shipt or Postmates?
Btw is this similar to Marqeta‘s JIT solution?
Does this work in all banking jurisdictions?
Looks like a great product and props to you and your team for shipping this.
You could pre-approve the transaction and then confirm it within 2 sec though.
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.
It adds a step during checkout where you are redirected to your bank/card issuers page to answer some security questions.
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 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.
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?
1. Who is the back-end issuer of the cards?
2. Are we talking credit, debit, or both?
3. What are the associated fees (issuance, re-issuance, branded issuance, charges)?
4. Is there any interchange revenue-sharing and if so, in what percentage?
Landing page have multiple cards of different types, including debit and credit.
> 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.
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, 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!
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.
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.
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
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.
> Plus, the population that is eligible for credit doesn't equal total population of the planet.
True, I'm talking about a hypothetical "maximal usage" future.
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.
> 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.
Credit card is 18 digits, which is where the 10^12 comes from.
(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...)
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...
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.
You would hope that Monzo is easy to replicate well because that means you have more modern banks to choose from.
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.
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.
This looks perfect though.
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.
It would make the CC numbers from database leaks a less valuable target since users could easily compartmentalize for every transaction.
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 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.
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:
Also, any chance for custom prints on the cards?
The cards draw from a Stripe balance, which can be funded from a connected bank account (or ordinary Stripe charges).
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 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?
Looked through the docs and meets the same needs that Emburse meets.
Cards draw from a Stripe balance (which is funded by payments that go through Stripe (or top-ups).)
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
> 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. But what Stripe has done is game changing.
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.
When a card is issued - do we get the card number back? e.g Could I use the card number for something else like a loyalty card.
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: found a way to disable: dom.vr.openvr.enabled in about:config (why does it trigger openvr?)