Dual Webhooks

In the Hybrid model, a single transaction can emit two webhooks: one in Long format (from Hosted/SDK, for the card) and one in Short format (from API Direct, for non-card methods, withdrawals, and refunds). This is by design.

Why duplicate webhooks arrive

Because each leg of your integration (SDK/Hosted for cards, API Direct for everything else) has its own webhook channel, you'll receive notifications from both. A single payment can generate a Pending event and then a Success for each channel involved.

What you need to configure

• Two webhook endpoints, one per integration style. With Webhooks 2.0, subscribe the card endpoint to the Checkout sessions — Hosted & SDK events and the other one to Payments — API Direct and Withdrawals (see the Events catalog). Without Webhooks 2.0 every registered URL receives both formats, so route by format in your handler.
• Separate handling logic: Hosted/SDK-style webhooks for card transactions, and API Direct-style for other methods, withdrawals, and refunds.

Deduplication checklist

• Dedupe on the webhook-id header with Webhooks 2.0 — a retry or a resend carries the same one. Without Webhooks 2.0, dedupe on id + event_type. Correlate with metadata.external_id, which repeats on every event of a transaction and works across Short + Long formats.
• Keep processed webhook-ids for at least 60 days — an event can be resent while it is kept.
• Keep an idempotency_key index in your DB.
• Treat duplicate Pending + Success in Hybrid mode as intentional.
• Always verify final status via GET /api/v1/transactions/{id}/.
• Handle all five withdrawal terminal states — Success, Declined, Cancelled, Failed and Returned; Returned arrives after Success.

Next steps