We support gift card payments directly through our API with support for split tender across traditional payment methods and gift cards, as well as automatic reversal.


Currently, we support gift cards through Qwikcilver only.

API endpoints

The API for gift cards consists of the following endpoints and API features.


As part of processing gift cards, we support the ability to automatically revert an authorized payment method or redeemed gift card before it is reverted.

The logic for this feature is as follows.

  • When a transaction occurs, regular payment methods are authorized (or captured) first, depending on their support for delayed capture.
  • Gift cards are only redeemed after the (optional) regular payment method has succeeded to authorize/capture.
    • When no regular payment method is present, gift cards are always redeemed.
  • In the case that any of the gift cards failed to redeem, any redemptions of other gift cards and regular payments are reverted.
    • In the case of Qwikcilver, gift cards are processed in a batch mode so any failed gift card will automatically result in all gift cards failing.
    • In the case of an authorized or captured regular payment method, the transaction is reverted by either voiding the authorization or refunding a capture.

In some cases, gift card redemptions will not be reverted. Please see the anti-fraud section below.


There are two fields returned by the transaction API which allows you to quickly understand if the original intent of a transaction was met.

  • The multi_tender (boolean) field indicates if the transaction included more than one tender.

  • The intent_outcome (enum) field indicates if the original intent (authorize / capture) was met. This field will be set to either pending if the transaction has not completed yet, succeeded in the case all tenders were processed successfully, and failed if any of them failed.

    This field does not change value after the succeeded or failed status has been achieved, even if the transaction is subsequently captured, voided, or refunded in any way.

    "type": "transaction",
    "id": "89bdaeeb-4be8-4ab7-a9e2-6f2c3da5f2d0",
    "intent": "capture",
    "multi_tender": true,
    "intent_outcome": "succeeded",

Reversals and anti-fraud reviews

There is a key difference in how reversals are handled when a transaction encounters any kind of halt in processing. This will happen when the transaction is held in anti-fraud review.

In these situations, if the approval fails, or if the transaction is rejected, the gift cards will not be refunded. The reason for this is that because of the time delay between the redemption and refund the user may no longer have the gift card at hand anymore.

Stored gift card filtering

Our API automatically removes any gift cards stored for a buyer with a zero balance or an expiry date in the past. When you add a new card, you may receive an error informing you that you’ve hit the limit of the number of stored cards (defaults to 10).

You will need to actively call the GET /buyers/gift-cards to clear out any expired and zero balance gift cards.


By default, the number of gift cards that can be used at the same time is limited to 10. This limit applies to the APIs for querying gift card balances, processing gift cards, as well as the number of gift cards that can be stored on a buyer.

To change this limit, please reach out to our support team.

Pending features

The following features are still in development and will be added in the coming weeks.

  • Support for declines using Flow for transactions not involving scheme cards.