Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe Issuing – An API for creating physical and virtual cards

stripe.com

Post reply on HN
Print view View original

101–110 of 217 posts

Re: Stripe Issuing – An API for creating physical and virtual cards

#101

Post by kbuck »

miketery wrote: post #93
ryandrake wrote: post #85

Earlier quoted context omitted.

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.

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.

Re: Stripe Issuing – An API for creating physical and virtual cards

#102

Post by VectorLock »

pbreit wrote: post #42
the8472 wrote: post #11

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.

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.

Re: Stripe Issuing – An API for creating physical and virtual cards

#103

Post by toyg »

jotm wrote: post #78
brentjanderson wrote: post #19

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 AP…

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.

Re: Stripe Issuing – An API for creating physical and virtual cards

#107

Post by driverdan »

tbgvi wrote: post #92
lachyg wrote: post #68

Earlier quoted context omitted.

(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…

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.

Re: Stripe Issuing – An API for creating physical and virtual cards

#108

Post by baby »

ljm wrote: post #48
AJRF wrote: post #41

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

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 w…

Monzo's first competitor is Revolut.

Re: Stripe Issuing – An API for creating physical and virtual cards

#109

Post by VectorLock »

ikeboy wrote: post #70
vishnugupta wrote: post #58

Earlier quoted context omitted.

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.

Can you expound a bit on what the rules are?

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

Post reply on HN