1.8. Return Transactions

Introduction

Return: Return transaction means returning money back to a Payer’s credit card or other type of account. Returned funds are not instantly displayed on Payer’s banking account, refund processing by Acquirer can take several days after it has been initiated. Return can only be processed for Sale, Preauth and Capture transactions in the final successful status. For Preauth it makes Cancel transaction, for Capture and Sale – Reversal. See Statuses.
Void: Void transaction sometimes can be used instead of Refund transaction to return money back to Payer’s account. Void request excludes transaction from Acquirer’s clearing list. The transaction can only be voided if it has been authorized but not settled yet. If clearing already happened or Void is not supported, it’s only possible to return funds to Payer’s account with Refund transaction.
Void can only be processed for Sale and Capture transactions in the final successful status, Void request makes Void transaction. See Statuses. Void might not be supported in most cases, ask support manager for details.

See terms definitions in Glossary.

Return Transaction Flow

skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 100 skinparam sequenceParticipant underline actor Payer participant "Connecting party" as A participant "Payment Gateway" as B hnote over A,B : Successful Sale, Preauth or Capture transaction autonumber group Optional Payer -> A: Initiate Return activate A end == Return == A -> B: api/v2/return activate B B --> A: Order ID B -> B: Process Return group Get Final Status == Receive Connecting Party Callback == A <- B: Callback with Final Status A --> B: HTTP 200 deactivate B == Order Status Request == A -> B: Get Status by Order ID api/v2/status activate B B --> A: Response with Status, Order-stage deactivate B end group Optional A --> Payer: Final Status deactivate A end

(1) Return can be initiated by Connecting Party based on internal business process or by Payer’s request.
(2) To implement return request see /api/v2/return/.
(5) Callback for Return will be sent only if notify_url was provided in initial transaction request or additional callback URL for Return transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Return will not be sent. To implement callback with final status handling see Connecting Party Callbacks.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(9) Final Status can be sent by Connecting Party based on internal business process or Payer’s request.

Void Transaction Flow

skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 100 skinparam sequenceParticipant underline actor Payer participant "Connecting party" as A participant "Payment Gateway" as B hnote over A,B : Successful Sale or Capture transaction autonumber group Optional Payer -> A: Initiate Void activate A end == Void == A -> B: api/v2/void activate B B --> A: Order ID B -> B: Process Void group Get Final Status == Receive Callback == A <- B: Callback with Final Status A --> B: HTTP 200 deactivate B == Order Status Request == A -> B: Get Status by Order ID api/v2/status activate B B --> A: Response with Status, Order-stage deactivate B end group Optional A --> Payer: Final Status deactivate A end

(1) Void can be initiated by Connecting Party based on internal business process or by Payer’s request.
(2) To implement void request see /api/v2/void/.
(5) Callback for Void will be sent only if notify_url was provided in initial transaction request or additional callback URL for Void transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Void will not be sent. To implement callback with final status handling see Connecting Party Callbacks.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(9) Final Status can be sent by Connecting Party based on internal business process or Payer’s request.