1.14. 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

(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

(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.