Idempotency

Making writes safe to retry.

Network calls fail after the server has acted. For anything that moves money, you need a key that lets a retry resolve to the same operation.

​

Supply your own reference

Payout and collection endpoints accept a merchant-side reference. Generate it once, store it before the call, and reuse it on every retry of that same logical operation.

const reference = `order-${orderId}-payout`;   // stable across retries

Never derive it from a timestamp or a random value created inside the retry loop — that defeats the purpose.

​

On the receiving side

Webhook deliveries can repeat. Treat data.Id as unique and make crediting conditional:

INSERT INTO settlements (flick_id, order_id, amount)
VALUES ($1, $2, $3)
ON CONFLICT (flick_id) DO NOTHING;

If the insert affects no rows, you have seen the event already. Return 200 and stop.

​

Reconcile anyway

Idempotency keeps you from double-acting; it does not tell you about an event you never received. Reconcile against Transaction history on a schedule and investigate anything settled at Flick but not in your ledger.