Acknowledge order of webhook events

[waiting-for-dev]

There's no guarantee that webhook events will arrive in the correct order. For instance, we could get authorization before a failure but be the reverse instead.

Partially replaces #160

[loicginoux]

the doc refering this https://stripe.com/docs/webhooks/best-practices#event-ordering
the solution for this seems tricky.
the event creation date (the event payload contains a created_at) is not a good source of truth. The last created is not necessarily the correct "final" state.
A solution I have heard is to have internally a state machine of the object in relation to the event (an intent or a charge) that follow the state machine of the stripe object, and validate that a trnasition is possible given an event received...
Not sure that this method covers all cases. I'll domore research on it in the next few days

[waiting-for-dev]

Thanks for your feedback, @loicginoux!

the event creation date (the event payload contains a created_at) is not a good source of truth. The last created is not necessarily the correct "final" state.

Hmm, are you sure? I understand that they're generated in order, but the delivery doesn't need to happen in that same order. From the docs:

Stripe does not guarantee delivery of events in the order in which they are generated.

Good point about maintaining an internal state machine.

[loicginoux]

I had a chat with a developer in the process of releasing Stripe payment for his company, he is more advanced in the implementation and gave us few technical advises after he had support from a Stripe Customer Solution Engineer. The Stripe team member advised him to do it this way. I still need to investigate more and we will definitely need to confirm that with Stripe support as well. I'll let you know when I have more information

[waiting-for-dev]

The solution here is not trivial and challenging to tackle without adding other infrastructure. An application should:

• Receive the webhook.
• Return a 200 to Stripe.
• Validate the operation to perform (like the state machine proposed by @loicginoux, but we can also leverage the Solidus' state machine can_? methods).
• If not possible, schedule for retry with whatever worker processor is used.

Like in #188 (comment), allowing applications to configure the adapter for Omnes subscribers would at least open gates for per-use-case implementations.