2 min read
Expose and register
Stand up a public HTTPS endpoint (Credicorp will not deliver to plain HTTP) and register it. In development, tunnel a local server to a public URL so you can receive real deliveries. The endpoint receives the signed events you subscribed to.
Verify, ack fast, process async
On each delivery: verify the signature over the raw body, enqueue the event, and return a 2xx immediately. Do the heavy work in a background job — a slow synchronous handler risks a timeout, which Credicorp reads as failure and retries, multiplying duplicates.
Make it replay-safe
Because delivery is at-least-once, de-duplicate on the event ID and process idempotently. Order by state, not arrival. Together these turn Credicorp's at-least-once delivery into exactly-once effect on your side.
Frequently asked questions
Can my webhook endpoint be HTTP?
No — it must be public HTTPS. Credicorp signs and delivers over TLS only. In development, tunnel your local server to a public HTTPS URL to receive real deliveries.
Why return 2xx before processing?
To avoid a timeout. Verify and enqueue synchronously, return 2xx, then process in the background. A slow handler triggers a retry, which just creates more duplicates for your idempotent consumer to absorb.
Related reading
Verify a webhook signature
Never trust an unverified webhook. Recompute the signature over the raw request body with your endpoint…
Read →Build an idempotent webhook consumer
Credicorp delivers webhooks at-least-once, so duplicates and out-of-order arrivals are normal. De-duplicate…
Read →
Mirror partner state into your systems with webhooks
Mirror Credicorp state by consuming webhooks idempotently and reconciling with reads after any outage…
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.