Osiris

[dry swift]

Good question. Trying to think of what you can do here to prevent that double charge

[steel cliff]

I am not getting enough sleep due to this question 😆 . My current solution is using increment with sequential processing via kafka queues. (to avoid timestamp clashes)

[dry swift]

Gotcha. Is that to say you have already tried to aggregate this on your side? I can definitely see something like waiting for the second to be over and then sending out usage for anyone who used during then.

I didn't find much myself on the API side here but will reach out to my colleagues who may know more

[dry swift]

One thing that I can think of that you can consider is using our library's idempotency functionality https://stripe.com/docs/api/idempotent_requests

You could potentially do something like make an idempotency key that is the subscription ID + your timestamp. That being said you would probably need some kind of logic to use a slightly different idempotency key if one of those requests fails.

Like sub_123-1680100000 could be the initial key for a subscription at a certain time. But if that request failed, passing us the key sub_123-1680100000 again would just have us resend that failure to you. So you would need logic to identify that and then send sub_123-1680100000-1 so that we would actually attempt that action again.