3 ms·

I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare. What do you mean by "there's no support for transaction

I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare. What do you mean by "there's no support for transactions"?

IshKebab 6y ago
He means database transactions. I.e. the ability to do a series of operations atomically.
arp242 6y ago
I haven't really worked with PayPal, so I can't really compare. I did some payments years ago with ... I forgot, so I can't really compare it to other competitors. With transactions I mean that if I send two or more API requests to complete a single action (e.g. "create customer and subscribe to plan", but there are many more advanced workflows like accepting multiple currencies etc.) then I'd like to have all of them succeed, or none of them succeed, similar to "BEGIN [..] COMMIT" in SQL. Right now, a network error, programming error, wrong data, or whatnot on the second request means I'll be left with a "dangling" customer. As far as I know, there isn't any good way to solve this other than either deleting the customer on errors or changing the first request to a "create if not exists"-type request. It works, but it's a lot less smooth than it could be. There are also some other concern with this; what if I send the same series of requests at the same time? The first might create object A, the second "create or get" might get the object created in the first series, and it all becomes messy and complicated. The only things Stripe offers now is "Idempotency-Key", which is not even a "poor man's transactions".
- jacobsenscott 6y ago
  I see what you mean, but I've never used an API where you could wrap arbitrary sets of API calls in a transaction on the remote side. In general once you are in the distributed systems world there are no transactions. I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway. So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first. Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?" With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back. * If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic. The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once. Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.

I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare. What do you mean by "there's no support for transactions"?

IshKebab 6y ago

He means database transactions. I.e. the ability to do a series of operations atomically.

arp242 6y ago

I haven't really worked with PayPal, so I can't really compare. I did some payments years ago with ... I forgot, so I can't really compare it to other competitors. With transactions I mean that if I send two or more API requests to complete a single action (e.g. "create customer and subscribe to plan", but there are many more advanced workflows like accepting multiple currencies etc.) then I'd like to have all of them succeed, or none of them succeed, similar to "BEGIN [..] COMMIT" in SQL. Right now, a network error, programming error, wrong data, or whatnot on the second request means I'll be left with a "dangling" customer. As far as I know, there isn't any good way to solve this other than either deleting the customer on errors or changing the first request to a "create if not exists"-type request. It works, but it's a lot less smooth than it could be. There are also some other concern with this; what if I send the same series of requests at the same time? The first might create object A, the second "create or get" might get the object created in the first series, and it all becomes messy and complicated. The only things Stripe offers now is "Idempotency-Key", which is not even a "poor man's transactions".

jacobsenscott 6y ago
I see what you mean, but I've never used an API where you could wrap arbitrary sets of API calls in a transaction on the remote side. In general once you are in the distributed systems world there are no transactions. I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway. So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first. Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?" With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back. * If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic. The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once. Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.