Am I understanding correctly that if you authorize and then don't charge for 7 days, the auth expires? So that would eliminate a kick starter, 30 day model?

Many cards don't support authorizations that last for 30 days. Kickstarter doesn't actually authorize cards for exactly this reason.

Do you know how PayPal does it? They have a 30 day auth validity, and in some cases there's an option to extend the auth past the 30 days.

We use PayPal a lot for our e-commerce store, and have verified the 30 day auth with near 100% success.

PayPal stores card numbers. If an authorization expires they can just re-authorize. Those details are hidden from you.

> So that would eliminate a kick starter, 30 day model?

You'd have to store the credit card number so that you can auth & capture when needed, rather than only store a temporary authorization token, which is exactly how those sites work now. Kickstarter gets your permission to charge your Amazon account, and Amazon charges one of your cards on file when the project is funded -- there's no long-standing authorization tying up funds for a month.

That was might first thought too. I think that's correct.

Why is this on the front page? A basic feature every gateway has had since time immemorial.

Sorry if it's annoying. I think it may be because a lot of HN users also use Stripe and because it was a notable omission to date. We initially leaned against supporting it for a long time because we hoped it was an implementation detail we could abstract away. In many cases where we've made decisions like this, it's worked out well, but in this case, we decided we'd gone a little too far and that the additional control was valuable.

Thanks. I'm glad you have implemented it; I've hoped for it since you guys told me in so many words in a campfire chat I was doing it wrong because I needed deferred capture, which I remember finding quite arrogant. That said, it's great to know you take on board user feedback when iterating Stripe.

Hi Patrick, what book or reference you would recommend to understand the whole payment business, by this i mean for example the steps involved in a credit card authorization, what is the flow of information between acquirers and issuers, that sort of thing.

    it was a notable omission to date

That's the reason I submitted this.

I have been using Stripes and Braintree's "Store/Verify then Charge Later" model in SaaS apps I build for customers in the service(Reserving services in advance) industry.

I have found that better that the original Auth/Capture flow since the final amount to be charged can be highly variable. Can anyone shed some light on when/if this auth/capture approach might make more sense in this type of use case?

You can follow a model similar to say hotels, where they auth the card for the room charge + expected incidentals, and then charge for the actual amount at the end of the stay. The amount you capture can be less than the amount you authorized.

> The amount you capture can be less than the amount you authorized.

The amount you capture can also be more than the amount you authorized, but how much more depends on the bank and is not known until you try.

It actually depends on the merchant category code (MCC) of your merchant account when it is setup. Only certain category codes, such as hotels and gas stations, are allowed to capture for more than they authorize.

I had no idea that the "authorize but don't capture" and "capture" buttons in Shopify were fake when using Stripe, their default payment integration. I guess I gave someone bad advice when I recommended he only authorize orders and capture them when shipping; if Stripe didn't support authorizations only, he's been capturing every sale regardless of what Shopify said. Oops.

Don't worry, they're not fake :). They've been beta testing the functionality for a while.

The early implementation of Stripe in activemerchant (library that Shopify uses for payments) didn't have a auth/capture capability. So the early version of Stripe captured everything as soon as the cart was checked out.