Cashless Payments

source dest

With Cashless payments, no payments are actually associated with the gift. This payment type can be used whenever you’re sending a greeting or gift that contains only media

Parallel Payments

source dest

With Parallel payments, the partner is responsible for distributing the payment independently of the gift. When a user opens this gift, they will see an image and dollar amount representing the payment, but the payment will have been sent independently at the same time the gift was created

Use-cases

  • P2P payments without interrupting payment

Flow

parallel flow

Data

Example source data (voucher.paymentInfo.sourceInfo):

{
  "type": "PARALLEL_TEST",
  "module": "PARALLEL",
  "approved": true
}

Example redeem data (voucher.paymentInfo.redeemInfo)

{
  "type": "PARALLEL_TEST",
  "module": "PARALLEL"
}

Passthrough Payments

source dest

With Passthrough payments, information placed into the payment source when a gift is created is what comes out in the redeem info when claimed. This is the perfect way to deliver a redemption url, coupon code or other such payment to the recipient where all the payment details are known when the gift is created

Use-cases

  • P2P payments where the recipient needs a redemption url
  • Delivering coupon-codes or gift cards where the information is provisioned by the sending client.

Flow

passthrough flow

Data

Example source data (voucher.paymentInfo.sourceInfo):

{
  "type": "PASSTHROUGH_TEST",
  "module": "PASSTHROUGH",
  "voucherInfo": {
    "redemptionUrl": "https://redeem.partner.com/code/123456789",
    "confirmationId": "12345"
  },
  "approved": true
}

Example redeem data (voucher.paymentInfo.redeemInfo)

{
  "type": "PASSTHROUGH_TEST",
  "module": "PASSTHROUGH",
  "voucherInfo": {
    "redemptionUrl": "https://redeem.partner.com/code/123456789",
    "confirmationId": "12345"
  }
}

Callback Payments

source dest

With Callback payments, you can have the most deeply integrated payments experience. When the gift is created, claimed or expired, callbacks are triggered that hit the partner’s own backends, allowing for deep integration and triggering provisioning of payments, or releasing of funds when the gift is actually claimed.

Flow

callbacks flow

Use-cases

  • advanced integrations where the payment is initiated on the client, but should be managed by backend services
  • payments where the gift should be provisioned at the actual claim time

Overview

The partner is responsible for providing web-services that will listen to callbacks / webhooks

Endpoints

There are 2 separate callback endpoints that can be set when configuring callback payments.

Create Callback

This endpoint is called when a gift is initially created. The information passed to it will include Sender, Recipient, amount, currency and any payment details provided by the client.

As a response, it expects either an Error message, along with an error status code if the payment failed, or any payment information you want added to the ‘source’ or ‘destination’ when it’s returned.

Claim Callback

This endpoint is called when a gift claim is completed. The information passed to it will include Sender, Recipient, amount, currency and any payment details provided by the sender, as well as any additional payment info provided by the recipient.

As a response, it expects either an Error message, along with an error status code if the payment failed, or the redemption payment info that the receiving client needs to show the successful claimer.

Sample Callback Services Project

We’ve created a sample web service project CallbackServiceSampleProject that you can clone and base your own Callback Payment Services off of. It is written as a spring-boot project and includes all the validation and transfer objects you need to communicate with our system.

Integrating Payments Client-Side

To integrate custom payments with your own behaviour or UI on mobile or web clients, follow the following guides: