#a55-design

1 messages · Page 1 of 1 (latest)

dry lichen
#

Hey @honest fern let me have a read

#

@honest fern damn that's a complex business model 😅. Manual capture could work yes but it is limited to a small subset of payment methods. Also this is not a great experience for your end customers who are literally paying and getting money held, sometimes for days, because of your setup/approach.
The way most businesses do this instead (concert tickets, plan tickets, etc.) is to "hold" the item for a limited time and prevent anyone from checking out otherwise

#

but overall your approach could work. We also are working on a beta of the Orders API https://stripe.com/docs/orders and we want to support inventory management there which would likely help

modest smelt
#

Is there a public roadmap for the orders api? Wondering when on_behalf_of might be available.

dry lichen
#

No public roadmap for now but you can discuss this with our support team

honest fern
#

Thanks for the prompt response! Some follow ups,

Could you direct me to some info that shows which payment methods support manual capture? I couldn't find that info. We're staying with card payments for a bit, and I assume that is okay.

Using the "lock" strategy was one of the original considerations. I tried to move away from it for a few reasons. Someone could always abandon a payment attempt, and then the invoice would be locked for X amount of time without cause. Holding the lock long enough can be tricky, as we would need to wait for the payment to be successfully and for the webhook to arrive.

Are there any guarantees on timeframe for webhook arrival? A potential issue here would be that the lock would expire, before a webhook confirming a success / other status would arrive. Sure, we could update the lock after the client side network call finishes so that it's a different form of lock (It would wait for a webhook), but this is unreliable.

I took a brief look at the Orders API however I see it does not support on_behalf_of which we utilize.

dry lichen
#

I don't think we have detailed docs for this but it's card, Afterpay and Klarna today

#

Holding the lock long enough can be tricky, as we would need to wait for the payment to be successfully and for the webhook to arrive.
You could just look at the PI before "releasing the lock" to avoid race conditions

honest fern
#

I see. So in this case we would have a guarantee lock period of X minutes. After which point we can check the assigned PI and handle the gap period between webhook delivery.

Do you think there may be another way of solving the overall problem? Essentially it seems like we’re forced into using different PIs that unfortunately, don’t have a way of linking to each other. Are there more structured approaches, such that for example, we can pay for a collection of PIs instead of doing it in ad-hoc method using the metadata?

I suppose Orders may help with this eventually?