Refund flow

Overview

Refunds can be initiated by an active user action (pressing the 'Refund' button) or can be triggered automatically on a user's behalf. Regardless of the trigger, a refund request will be sent from Google to the integrator.

How the flow works

Here is an example refund flow initiated by the user:

Refund flow

Refund flow

Here is the list of objects in the above diagram:

  • User: This is the person who wants a complete or partial refund.
  • Google Server: The backend server at Google that sends the refund command to the Payment Integrator Server.
  • Payment Integrator Server: The backend server of the integrator that accepts the request for a refund.

The refund in this example is initiated by the user.

  1. User initiates the refund to the Google Server.
  2. Google Server calls the Refund endpoint on the Payment Integrator Server.
  3. The Payment Integrator Server responds with Success.
  4. The User gets a refund.

Best practices and other considerations

Because some Google products, such as Adwords, support refunds as long as credit in the account exists, transaction refund requests should be supported for an indefinite duration. If a technical limitation exists, the refund period should be as long as your platform allows.

If the GPT has expired, the refund should still work. Refunds can only be declined if the balance on the original transaction is not enough to cover the refund amount, or the account has been closed or is on hold and the integrator has no ability to send the user this money.

Refunds can be initiated within seconds after the capture. The timing of refunds is at Google's discretion.

A refund should never be assumed as a full refund. The refundAmount field must always be considered when refunding the account.

Multiple partial refunds must be supported. For example, let’s say a transaction worth $11.00 occurs, and a user can refund $4.00, $5.00 and $1.00 from the original transaction. In this case, all three refunds will have the same merchantTransactionId, but different requestId values. Further, this transaction would have just $1.00 left on it.

Now let’s imagine there is a $12.00 purchase. For this example, the user can make two refunds, each of $6.00. If these two refunds have different requestId values (and the same merchantTransactionId) they must be treated as separate refunds on the same transaction. In this case the user would have $0 left on the transaction once these refunds are complete.