Integration flow

What a complete integration does, in order. Each step names the rules it follows from Integration rules.

Create

Generate merchant_reference, save it with your order, then call the create endpoint of the method. (R4)
On a timeout or a dropped connection, resend the identical request. (R6, R14)
If your own endpoint is called again — the payer clicks Pay twice, your process restarted — look the transaction up with GET /v2/transactions?merchant_reference=… before creating. Never store card numbers or CVC to replay a request. See Idempotency. (R4)
Save id, status and next_action from the response. Then wait for webhooks; reading the status is only the fallback. (R8, R20)

On requires_action, send the payer to next_action.redirect.url, or ask them to confirm in the banking app, before next_action.expires_at. The step can also arrive later by webhook: keep the latest next_action with the order so your frontend can show it — see Payer actions. (R10)

On authorized, call capture or void. A repeat of the call is safe; after payin.capture_failed or payin.void_failed call it again. (R5, R11)

Verify Webhook-Signature with the secret of the shop the URL or shop_id names. (R15)
Store the event by its id and answer 2xx; process it afterwards. (R16, R17)
Processing: apply data.object from the event, then mark the event processed. (R17, R18)
Fallback: if no webhook has come for a minute, you can start polling the status with GET /v2/transactions/{id} until it is final. (R20)

A final status never changes, except a payin completed → refunded: once a final status is applied, a late webhook, a retry or an overlapping sync changes nothing. (R8, R19)
completed — release the goods, once. failed — show status_details.code. Anything else — keep waiting. (R8, R9, R13)

On a schedule, sync by change time with order=updated_asc and an overlapping window — see Transactions. (R19)

Then prove it in the Sandbox with the integration checklist.

Next: Card payin