Stripe Issuing – An API for creating physical and virtual cards | Hacker News Reader

Stripe Issuing – An API for creating physical and virtual cards

stripe.com

742 pointszuck9215 comments

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 :)

(I work on Stripe Issuing.)

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).

Yes!

So we can build an e-wallet service with Stripe Connect? If so, I would love to get in touch to discuss more!

or a platform that needs to purchase goods in the real world

So like Shipt or Postmates?

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.

Been waiting for something like this for a while. Much nicer if you can keep a ledger of these auth'd cards and revoke if need be.

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.

Privacy.com does this

link: https://privacy.com

I have been in US for 10 years and have had this since the first time in I opened an account in BOFA. The feature is called ShopSafe

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.

Yes, ShopSafe is useful when dealing with flaky businesses.

Privacy.com is doing this today although it’s a debit card (AFAIK).

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.

Citibank already offers this feature on their credit cards, I believe: https://www.cardbenefits.citi.com/Products/Virtual-Account-N...

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.

I've been watching Revolut who introduced something like this a while back https://blog.revolut.com/introducing-disposable-virtual-card...

I used that for a while, until a billing network banned me for using too many cards with my name.

i'm thinking about using privacy.com, what ended up happening? What is a billing network?

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 has similar virtual cards for a ~4% fee

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.

True, I remember my card at Entropay being registered under Malta, Europe. But fortunately, online services accepted it.

Do you remember how you checked this? I wonder if there's a BIN lookup somewhere.

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. :(

GetFinal was acquired by Goldman Sachs which may or may not fit your definition for "folded".

Probably to shelve the idea.

Proven teams from unprofitable ventures are frequently acquired to work on other business ventures with higher likelihood of success.

Check out privacy https://privacy.com/

Have you looked into the existing options? Citi and Bank of America for example support virtual card numbers (virtual account numbers and ShopSafe, respectively).

Capital One does, as well. Unfortunately, it requires a browser extension, which I'm not a big fan of.

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.

Could you MITM the extension to reverse engineer the API calls it makes and write a command line tool to perform the required functions?

I have a friend at CapOne, I’ll ask tomorrow.

Startup idea of the week

What would be good, would be to have a card number generated that expires 10 minutes later, that you could use as a "one time code" to purchase stuff

As a previous commenter mentioned Revolut do this.

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...

I use privacy.com which is awesome

Just signed up and had a poke around, created a few cards. I have to agree it looks excellent.

To save others a click - looks good, but US-only.

As others have said, try out Revolut. I believe it's only part of the premium package which sucks, but they offer throwaway cards for this purpose.

Check out Capital One. They have the ability to have multiple virtual cards that you can turn on or off.

https://www.capitalone.com/applications/eno/virtualnumbers/

Check out privacy.com for that.

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.

Pre-approving a transaction would do the trick and it wouldn't hold up the line, good call.

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.

There's actually an implementation of this for online sales in Europe (and probably other places in the world), it's called 3D Secure: https://www.visa.ca/en_CA/visa-everywhere/security/future-of...

It adds a step during checkout where you are redirected to your bank/card issuers page to answer some security questions.

Yeah, I need to open my banking app and approve the payment there. I think it needs to be supported by the vendor though

Do you think this API could be used to create non-card payment tokens? For instance an implanted Java card like the VivoKey[0]?

[0]https://vivokey.com/learn-more.html

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.

How do you fund a stripe account without taking payments as a merchant at stripe

Quick Q, who plays the role of the bank holding the backing funds? Or does stripe simply play the role of a transmitter,

Btw is this similar to Marqeta‘s JIT solution?

We play the role!

To confirm, you meaning Stripe?

Does this work in all banking jurisdictions?

He means Stripe (he introduced himself earlier in the thread), don't know the answer to the second q

lachyg - who is the sponsoring bank for the visa and / or mastercard BIN's you issue?

> 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.

https://galileoprocessing.com/ https://www.pexcard.com/

If you’re looking for real-time API hooks, as far as I know only Marqeta has this offering.

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.

Yes, Marqeta provides this - they call it JIT funding.

Yeah with $1m commitment over the next 12m lol.

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.

Fraud is what I keep thinking about. Hopefully Stripe put in place some robust tracking, or it will get messy.

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.

A couple of very important questions, which are not addressed on the landing page:

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?

On the landing page, you can see that it’s debit.

Really? It may be an A/B test with different copy, because I don't see anything.

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.

Mastercard's prepaid debit cards are quite popular with fintech startups.

From docs: "Learn how to create cardholders and issue credit cards to them."

Landing page have multiple cards of different types, including debit and credit.

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.

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.

Have a look at:

https://openplatformbbva.com

https://synapsefi.com

https://www.marqeta.com

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 would also add Thought Machine with their Vault OS product, looks interesting.

I can't even imagine how much work went into this. Stripe does a great job of tackling the toughest problems and making it looks easy!

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.

Considering how slow banks move on tech, I think this is exactly right.

Great point!

Will keep an eye out in the coming weeks for:

    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.

~Bosky

Any word on pricing? fees? cashback?

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.

Each issuer has 1 trillion possible account numbers.[0]

[0]https://www.creditcards.com/credit-card-news/credit-card-app...

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.

I see, by issuer do you mean "Visa", "MasterCard", etc.? Because there are only a handful of those.

> 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.

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.

You're right, I added an extra zero. It's one trillion numbers per issuer.

Credit card is 18 digits, which is where the 10^12 comes 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...)

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...

https://news.ycombinator.com/item?id=17524398

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.

Hrm, I'm really sorry to hear about these bad experiences. Could you share more with me? I'd like to look into them. edwin@stripe.com

Does this make something like Monzo seem trivial?

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).

(I work on Issuing.)

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.

[1] https://www.openbanking.org.uk

Monzo's first competitor is Revolut.

I would say Starling is more comparable. Both are licensed banks with FSCS protection.

Stripe invested in Monzo's last round I think!

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.

A lot of the banks are also big on leveraging their transactional data already.

I wonder if this would be a good replacement for GPS for new digital banks. I would love to say goodbye to their unstable service and SOAP API.

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.

Would this work in conjunction with Stripe Connect? E.g. for a marketplace-like service but instead of sending payouts, issue custom cards?

That would be a great use case for this.

Especially if it resulted in a lower Connect transaction fee when payouts are issued on Card.

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).

https://news.ycombinator.com/item?id=17468176

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.

This happens. A LOT.

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.

Why don’t you build a website with a cancel button?

Because we use third party services for everything and none of them have APIs.

Look at https://privacy.com/

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.

Can you use privacy.com without installing the chrome extension?

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.

Check out Revolut: https://www.revolut.com/?lang=en

They have virtual cards as well as a disposable one that changes number every time you use it online.

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.

Except a declined payment doesn’t take you off the hook for paying what is owed, so you could still find yourself in collections.

I've been on the site for five minutes and haven't found the pricing. Not a good sign.

if you have to ask it's probably not for you

Does Stripe bypass card networks when processing these cards for Stripe merchants? That would be very cool.

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.

This looks perfect though.

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.

(I work on Issuing.) Check out https://emburse.com/ -- they do this really well (and are a user!).

Check out privacy.com. they're debit cards technically, but most places accept them as credit with no issue.

Check out teampay.co

I wonder why this isn't standard service from every credit card provider, ideally as an app.

It would make the CC numbers from database leaks a less valuable target since users could easily compartmentalize for every transaction.

Because the work involved in creating eneyerprise scalable software platforms that deal with financial transactions is REALLY hard.

It's a massive undertaking for very little benefit. And there's a large group of card holders who hate when their number changes.

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 on the new product!

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.

Very cool.

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?

Absolutely happy to talk about travel use cases -- we are supporting it today. We also (only) support custom designs.

Wow interesting company being kept in the high risk businesses section. Travel is lumped in with hate groups, wonder why

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.

Wow! This is so cool that I am a little sad for currently not having a problem to solve with this yet! I really like Stripe.

Is this what Marqeta does?

Marqeta has a iirc ~$10k setup fee. I'm hoping that this is much more reasonable.

No they don't.

Marqeta is the API first leader in card issuing. Stripe just entered their space.

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.

They are in the US, Canada and I know they are in Europe. Will launch in a few months because we are working with them. They're awesome.

A service like this has been avaliable in Portugal from "Multibanco" as "MBNet" or "MBWay"

Is it just me or the card animation has rendering issues when scrolling? Using latest MacBook Pro 15"

I’m on an iPhone X, and when the animation is visible the scrolling performance is awful, seems like ~10 FPS.

My iPad started heating up as well when viewing the page, so it seems to use excessive resources

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?

(I work on Issuing.)

The cards draw from a Stripe balance, which can be funded from a connected bank account (or ordinary Stripe charges).

Thanks. Is there any documentation available on this? I can't find how a card is connected to specific bank account.

Docs: https://stripe.com/docs/issuing

Cards draw from a Stripe balance (which is funded by payments that go through Stripe (or top-ups).)

Will this be launched worldwide? If not, which countries in the first phase?

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.)

Roger from Emburse here. We're built on top of Stripe :D

Comdata?

We would be entirely API used for QA automation.

Looked through the docs and meets the same needs that Emburse meets.

Great use case! If you fill in the form at https://stripe.com/issuing (or email me at lachy@stripe.com) we'll get back to you soon.

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).

Why would the interchange fee be any different or get paid to anyone else in this instance?

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.)

Are these credit or debit cards? Asking because I've previously had issues with virtual debit cards where merchants "force posted" transactions through.

Looks like debit, the docs mention that purchases debit your stripe account balance.

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.

[1] https://stripe.com/docs/issuing/transactions [2] https://www.freecharge.in/mobile/freecharge-go

Edit: Minor correction.

That doesn't answer the question of which network and what rules the transaction is governed by.

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.

(I work on Issuing.)

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.

So who determines whether it's run as debit or credit? The business creating the card at time of creation? The merchant?

We do :-) But it's based on quite precise Visa / Mastercard rules.

Is this determined as issuance time or purchase time?

Can you expound a bit on what the rules are?

In my observation debit issuers make it much harder to do chargebacks.

Many protections in laws only apply to credit. See e.g. https://consumercomplianceoutlook.org/2016/first-issue/credi...

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.

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)

I see the man. So technically, it is a debit card instead of a credit card. Anyway, thanks for your reply.

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.

Haha, that mean I can lending loan to somebody now without any government regulation lol....

I've worked extensively in the card manufacture business. Does anyone know who manufactures and fulfils the card orders?

Similar to what privacy.com does for consumers

Fedora 28, Firefox 61. The linked page is too webscale for my browser, the tab crashes after a dozen seconds of scrolling.

Very cool. I'm wondering if the future of banking is actually online credit unions created using something like this.

On a side note, the card animation is interesting. I thought it would be some GIF but the text is actually selectable!.

Will these cards work at ATMs? If so, I can imagine that they’d be quite useful as a way to distribute petty cash.

Will this be opened up for all stripe customers or will it remain invite only? If so, is there a planned date?

(I work on Issuing.) Our product philosophy is making things as widely available as possible; we won’t be shy about letting the world know when we do.

Congrats team!

Awesome! Now it's official. I worked on MVP with Stripe Issuing API. That was a cool experience.

this is really cool and I have a couple of good ideas about how I could use this. Question is - how much does it cost for the card? Minimum volumes ?

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.

Love it, unfortunately it is currently by invitation only though. Anyone have any information about what the qualifying criteria is?

I would love to know this as well.

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.)

What gap in the market is Stripe filling? I'm not entirely sure what Stripe does.

Very off topic (sorry): does anyone have Steam VR launching when opening the linked story in latest stable Firefox on Windows 10?!

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?)

Reply on news.ycombinator.com