Response ID Fields

Technical Author Note

Drafted from sample content. Verify all field names, request/response examples, and status values against the OpenAPI spec or a real API response before publication.

The gateway returns several ID fields, and the same logical concept appears under different names depending on the operation. This page is the definitive mapping.

Naming asymmetry

• initial_operation_id appears only on originating direct-payment responses (sale, pre-auth, payout, funding).
• parent_operation_id appears on all back-office responses (capture, reverse, cancel) and links back to the originating authorisation/transfer.
• The top-level id always identifies the object returned in that specific response — never the same as initial_operation_id or parent_operation_id.

Per-operation mapping

Operation	Response field	Store as	Purpose
Sale	id	payment_id	Payment object UUID — used in the /reverse URL
Sale	initial_operation_id	transfer_id	Internal transfer ID
Pre-Auth	id	payment_id	Used in /capture and /cancel URLs
Pre-Auth	initial_operation_id	authorisation_id	Internal authorisation ID
Capture	id	transfer_id	Transfer operation UUID created by this capture
Capture	parent_operation_id	authorisation_id	Echoes the pre-auth's ID — confirms linkage
Reverse	id	transfer_id	Transfer operation UUID for this reversal
Reverse	parent_operation_id	(not stored)	Informational — echoes authorisation_id
Reverse	authorisation_id	authorisation_id	Conditional — present only when offline refunds are not allowed
Cancel	id	cancel_id	UUID of the void operation
Cancel	parent_operation_id	authorisation_id	Echoes the pre-auth's ID — confirms which pre-auth was voided
Payout	id	payment_id	Payment object UUID
Payout	initial_operation_id	transfer_id	Internal transfer ID
Funding (AFT)	id	payment_id	Payment object UUID
Funding (AFT)	initial_operation_id	transfer_id	Internal transfer ID

Key rules

• Never overwrite payment_id from a back-office response. Capture, cancel and reverse return their own id (the operation's UUID), not the payment's. The original payment_id is the URL path parameter for the lifetime of that payment.
• transfer_id, authorisation_id and cancel_id are for reconciliation and tracing, not for URL construction. Back-office endpoints only need payment_id in the URL.
• Capture and Cancel re-confirm authorisation_id via parent_operation_id.