2 min read
Consume the events
Subscribe to the application, decision and payment events. On each, verify the signature, then upsert your local record keyed on the resource ID — idempotently, ordering by state not arrival. This keeps your mirror current in near real time.
Reconcile after a gap
Webhooks are at-least-once, but if your endpoint was down past the retry window you may miss one. Run a periodic reconciliation: read the resources you care about via their read endpoints (paginating with cursors) and repair any drift. Webhooks are the fast path; reads are the safety net.
Model the money-out state
Mirror the payment status faithfully — provisioned, pending, settled — and remember that an approved decision is not yet funded because money-out is a governed gate. Represent 'approved, funding in progress' distinctly from 'funded' in your data.
Frequently asked questions
What if my webhook endpoint is down for a while?
You may miss events past the retry window. That is what the reconciliation read pass is for — periodically read the resources and repair any drift, so webhooks plus reconciliation together give you eventual consistency.
How do I avoid double-applying an event?
Verify the signature, then upsert keyed on the resource ID and de-duplicate on the event ID. An idempotent upsert makes a repeated delivery a no-op.
Related reading
Build an idempotent webhook consumer
Credicorp delivers webhooks at-least-once, so duplicates and out-of-order arrivals are normal. De-duplicate…
Read →Verify a webhook signature
Never trust an unverified webhook. Recompute the signature over the raw request body with your endpoint…
Read →Paginate a partner collection
Walk a partner collection with cursor pagination: pass a limit, follow next_cursor until it is null, and page…
Read →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.