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

81–90 of 217 posts

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

#81

Post by lachyg »

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.

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

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

#82

Post by lachyg »

ckdarby wrote: post #37
lachyg wrote: post #16

Earlier quoted context omitted.

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

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.

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

#83

Post by lachyg »

mholt wrote: post #47

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

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

#84

Post by tixocloud »

hobofan wrote: post #21

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

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

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

#85

Post by ryandrake »

lachyg wrote: post #68
TheTaytay wrote: post #54

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

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

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.

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

#87

Post by Immortalin »

lachyg wrote: post #76
ryanworl wrote: post #73

Earlier quoted context omitted.

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!

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

#88

Post by ikeboy »

lachyg wrote: post #81
ikeboy wrote: post #70

Earlier quoted context omitted.

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?

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

#89

Post by aloukissas »

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?

Post reply on HN