Recipe

Build an idempotent webhook consumer

Credicorp delivers webhooks at-least-once, so duplicates and out-of-order arrivals are normal. De-duplicate on the event ID, trust the event's state over arrival order, and make a replay a no-op.

2 min read

Event IDDe-dup key
State > orderNot arrival
No-op replayIdempotent

De-duplicate on event ID

Record every event ID you have processed. On receipt, check the store first: if you have seen the ID, acknowledge with a 2xx and stop — the work is already done. This turns at-least-once delivery into effectively exactly-once processing on your side.

Order by state, not arrival

Retries and parallel delivery mean a 'settled' event can arrive before a 'created' one. Do not assume arrival order. Key your state machine on the event's own type and timestamp, and ignore a transition that would move a resource backwards. Verify the signature first — see verifying a signature.

Acknowledge fast, process async

Return a 2xx as soon as the event is verified and enqueued; do the heavy work in a background job. A slow synchronous handler risks a timeout, which Credicorp reads as a failed delivery and retries — creating more duplicates. Fast ack plus idempotent processing is the stable pattern.

Frequently asked questions

How do I make processing exactly-once?

You cannot control delivery, but you can control processing: store each processed event ID and no-op on repeats. That converts at-least-once delivery into exactly-once effect on your side.

What if events arrive out of order?

Treat the event's own type and timestamp as truth, not arrival order. Reject transitions that would move a resource backwards. Never assume a 'created' arrives before a 'completed'.

Funding for UK limited companies

Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.