Handling refunds for asynchronous payment methods

Learn how to handle refunds for asynchronous payment methods.

After you submit a refund request on asynchronous payment methods, such as Wire Transfer, bPay, Online Banking, and Konbini, payment providers usually need to collect information from the customer before the refund can be issued.

When creating refunds on these types of payment methods, the Refund object is returned in a state of pending_information and contains the tokenInformation dictionary, which consists of a token and an expiresTime value. You can use the token in subsequent refund requests to first GET the schema that defines the data fields the customer must provide and then POST the collected data.

Digital River creates an Event object that persists for 30 days when a Refund transitions to a state of pending_information. The Event has a type of refund.pending_informationand a data attribute that contains the Refund object itself.

To subscribe to these events, create a webhook that listens for refund.pending_information events. When you receive the event, redirect your customer to the payment provider for authorization.

The following steps explain, at a high-level, the process for handling refunds for an asynchronous payment method:

  1. Submit a create refund request.

  2. Payment services return a Refund with a state of pending_information and a new tokenInformation hash.

  3. When you receive a refund.pending_information Event, use the createElement function exposed through the DigitalRiver object to provide the tokenInformation to DigitalRiver.js.

  4. DigitalRiver.js then sends the tokenInformationto payment services, requesting the schema that defines the required fields, which are then displayed to the customer.

  5. The customer enters their data.

  6. DigitalRiver.js submits the customer provided data to payment services.

  7. Digital River triggers a new webhook when the Refund state changes from pending_information to succeeded or failed.