Custom Payment Links Integration

​

Steps to Integrate Custom Payment Links

​

Create Session and Payment Using Checkout API

The required Request parameters are:

{
  "payment": {
    "amount": "string", // up to 2 decimals for UAE and KSA, e.g. 100.00
    "currency": "string", // use the ISO 4217 standard for defining currencies
    "buyer": {
      "phone": "string" // required for sending Payment link. Not required for QR-code
    },
    "order": {
      "reference_id": "string", // merchant's Order Number to match the order with the payment.id
      "items": [
        {                    
          "title": "string", // Name of the product.
          "quantity": 1, // Quantity of the product ordered. Should be >= 1
          "unit_price": "0.00", // Price per unit of the product. Should be positive or zero.
          "category": "string" // Required as name of high-level category (Clothes, Electronics,etc.)
        }
      ]
    }
  },
  "merchant_code": "string" // merchant's branch code
}

Even though other parameters are technically optional for offline integration, we highly recommend sharing other data marked as required in the API Docs, as additional data allows Tabby to increase the AOVs and conversion approval rates.

​

Background Pre-scoring Checks

As a response you receive one of the two session statuses - “created” or “rejected”:

• if the session status is “created” - save the session_id (it will be required for notification and cancellation steps) and payment_id (will be required for payment verification and refund steps) received in the response:

"status": "created"
"id": "string"
"payment"."id":"string"
"payment"."status":"CREATED"

• if the session status is “rejected” - inform the cashier that the customer is not eligible for Tabby and offer the customer an alternative payment method. Please, do not proceed with any further steps with Tabby. The response payload will containt the following:

"status": "rejected",
"configuration"."products"."installments"."rejection_reason": "not_available"

The “rejection_reason” field can take the following values, you may add human readable messages from below to your system (optional):

​

Customer payment options

• First option: Send the payment link to the customer via SMS using Tabby Notification API (provided in a Postman Collection). You can use this method only if you send a buyer.phone and receive a “created” status in the response to the previous request.
• Second option: show the payment QR-code to the customer from the response available_products.installments[].qr_code. You can show it only if you receive a “created” status in the response to the previous request.

​

Payment Processing

Verify the payment status using:

• Webhooks
• or Retrieve Payment API call

​

Webhooks

• Tabby sends you a notification payment status update. The initial payment status is CREATED.
• If the Webhook with the authorized or closed status is received - mark the order as successful in your OMS. You can ignore other Webhooks received for this payment.id.
• If the Webhook returns a rejected status - mark the payment as unsuccessful and ask the customer to pay with another payment method.
• If no status is received - the cashier should have an option to cancel the payment.
  Optional: You can also add a cancel button using the Cancel Session API (provided in a Postman Collection) when you want to expire the Tabby session if a customer asks to pay with another payment method or start a new Tabby session.

​

Retrieve Request

An alternative way to verify a payment status is by polling status with the Retrieve Payment API call. You can call Retrieve Request by cron or by cashier’s action (add button Check status to the POS). The following statuses can be received:

• CREATED - the payment has not been completed yet, wait for it to change to one of the terminal statuses.
• AUTHORIZED or CLOSED - a payment was placed successfully, mark orders as successful and proceed with the order on your POS/OMS.
• REJECTED or EXPIRED - a payment is not successful. Ask the customer to pay with a different payment method.

​

Cancel a Payment

A request to cancel a payment is available in the Postman collection. The payment can only be canceled if its status is CREATED. Once canceled - the status will change to EXPIRED.

If the payment has already been authorized, attempting to cancel it will return the following error: 400 Bad Request

{
  "status": "error",
  "errorType": "bad_data",
  "error": "session is finalized"
}

In this case check the payment status via the Retrieve Payment API call and verify the status is AUTHORIZED or CLOSED. Then show a success screen, print a receipt and proceed with the order.

​

Payment Refund

You can process a full or partial Refund. Call Refund API for a specific Payment ID with the desired amount. You can find the payment.id by matched payment.order.reference_id in your OMS.

You can also process a refund from the Tabby Merchant Dashboard.

​

Testing Scenarios

Kindly verify that your integration can handle all listed below scenarios.

​

1. Payment Success

Testing Steps:

1. From a Cashier’s POS choose Tabby to create session and payment.
2. A session should be created with a real phone number.
3. Send a payment link as an SMS to the customer or show it as a QR code on the POS screen.
4. Open the link / scan the QR code.
5. On Tabby Checkout page use these credentials:

Positive flow:
UAE: otp.success@tabby.ai, phone: +971500000001
KSA: otp.success@tabby.ai, phone: +966500000001
Kuwait: otp.success@tabby.ai, phone: +96590000001

6. Complete the payment using OTP:8888 on Tabby HPP.
7. Verify that the capture of the successful payment occurred - check for status CAPTURED on the Merchant Dashboard or Payment status CLOSED via Retrieve Payment API call.

Expected Results:

1. Tabby is present among payment methods on Cashier’s POS.
2. Session creation response has status “created” - the customer is eligible to use Tabby.
3. A payment link is successfully sent as an SMS to the customer or shown as a QR code on the POS screen.
4. Tabby Hosted Payment Page opens.
5. The success Tabby screen appears.
6. Order is captured:
   • on Merchant Dashboard payment status is CAPTURED
   • via a Retrieve Payment API call response Payment status is CLOSED, captured amount is present in the “captures”:[] array of objects.

​

2. Background Pre-scoring Reject

Testing Steps:

1. From a Cashier’s POS choose Tabby to create session and payment.
2. Fill in all the required fields and use the following phone numbers:

Background Pre-scoring reject flow:
UAE: +971500000002
KSA: +966500000002
Kuwait: +96590000002

3. Attempt to create session and payment with Tabby.

Expected Results:

1. Tabby is present among payment methods on Cashier’s POS.
2. Session creation response has status “rejected” - the customer is not eligible to use Tabby.
3. Tabby payment method becomes hidden or marked unavailable, the following message can be shown (optional):
   • English: Sorry, Tabby is unable to approve this purchase, please use an alternative payment method for your order.
   • Arabic: نأسف، تابي غير قادرة على الموافقة على هذه العملية. الرجاء استخدام طريقة دفع أخرى.
4. Another payment method should be selected on Cashier’s POS.

​

3. Payment Cancellation

Testing Steps:

1. From a Cashier’s POS choose Tabby to create session and payment.
2. A session should be created with a real phone number.
3. Send a payment link as an SMS to the customer or show it as a QR code on the POS screen.
4. Open the link / scan the QR code.
5. Leave or abandon Tabby Checkout page.
6. You may additionally cancel the session from your side.

Expected Results:

1. Tabby is present among payment methods on Cashier’s POS.
2. Session creation response has status “created” - the customer is eligible to use Tabby.
3. A payment link is successfully sent as an SMS to the customer or shown as a QR code on the POS screen.
4. Tabby Hosted Payment Page opens.
5. After the payment is left / abandoned / cancelled a new session can be created from Cashier’s POS.
6. No order appears on the Merchant Dashboard (unsuccessful orders are not displayed on the Dashboard).
7. On checking Payment Status via Retrieve Payment API call it should be:
   • first - CREATED as the payment has not been completed;
   • after the cancellation from your side - EXPIRED;
   • if no cancellation has been sent from your side -> after 20 minutes from opening the link (sometimes plus additional 10-20 minutes) - EXPIRED.

​

4. Payment Failure

Testing Steps:

1. From a Cashier’s POS choose Tabby to create session and payment.
2. A session should be created with a real phone number.
3. Send a payment link as an SMS to the customer or show it as a QR code on the POS screen.
4. Open the link / scan the QR code.
5. On Tabby Checkout page use these credentials:

Negative flow:
UAE: otp.rejected@tabby.ai, phone: +971500000001
KSA: otp.rejected@tabby.ai, phone: +966500000001
Kuwait: otp.rejected@tabby.ai, phone: +96590000001

6. Finish the payment using OTP:8888 in Tabby HPP.
7. Verify the payment status via Retrieve Payment API.

Expected Results:

1. Tabby is present among payment methods on Cashier’s POS.
2. Session creation response has status “created” - the customer is eligible to use Tabby.
3. A payment link is successfully sent as an SMS to the customer or shown as a QR code on the POS screen.
4. Tabby Hosted Payment Page opens.
5. The rejection screen with the message ‘We can’t approve this purchase’ appears.
6. Tabby payment method is still available for selection on Cashier’s POS.
7. No order appears on the Merchant Dashboard (unsuccessful orders are not displayed on the Dashboard).
8. On checking Payment Status via Retrieve Payment API call it should be REJECTED.

​

Postman Collection

Find the Postman collection for the Custom Payment Links Integration via the link below.

1. Download the JSON file.
2. Import the JSON file from the downloaded archive into Postman.
3. Enter your Tabby Secret API Key and merchant_code into the appropriate Collection Variables.