Kript Pay Checkout (STANDARD)

Kript Pay Checkout is our "standard" payment flow that allows businesses to receive payments and orchestrate payment between 2 parties (the receiving party being a Flux user). Here's how it works:

• Customer A (the receiving party) links their Flux account with the business via scanning a QR code.
• From your server call the GET CHECKOUT URL endpoint with details of the payment to be made to Customer A.
• Redirect Customer B (the party making the payment) to the checkout page (returned from the endpoint).
• When customer successfully makes the payment we send a webhook event to your server.

📘

Payment Time Limit

After getting the checkout URL, the payment has to be made within an hour, after which the link would expire and the status would be updated to EXPIRED and a webhook event would be sent to your servers. For bank transfer payments, the assigned virtual bank account account the payment should be made to would be deactivated, so payment should no longer be made to that bank account. Instead another link should be generated using the same endpoint.

What happens after a successful payment

These things would happen when a payment is made successfully:

1. We'll send you a webhook event if you have that enabled. Learn more about webhooks and see examples here.
2. We'll send an email receipt to both your customers (the paying customer and the receiver).
3. We'll send you an email notification.
4. For bank transfer payments, the attached virtual bank account would be deactivated.

📘

Verify Payment

After receiving the webhook event on your server, always verify the state of the payment.

🚧

BANK TRANSFER PAYMENTS

Because bank transfer payments are from 3rd party apps (i.e other bank apps or bank transfer enabled services), we have no control over the amount the sender (paying party) transfers to the displayed bank account on the checkout page. So always lookout for the paid_amount field in the webhook event and verify payment. response. a successful paid with PAID status should have the paid_amount be at least equal to the charged_amount if it's less then the status would be INCOMPLETE.

🚧

Mutiple Payment Amounts

The payment object returned from the retrieve endpoint contains 4 amount fields: amount, charged_amount, paid_amount and settled_amount.

• amount: The expected amount the receiving part should get.
• charged_amount: The amount the paying party should send as payment, for BANK_TRANSFER payments this charged_amount might include the fee (i.e amount + fee) if you set the fee_bearer to PAYER.
• paid_amount: The actual amount paid by the sender (paying party). if this is less than the charged amount then the status of this payment would be INCOMPLETE.
• settled_amount: The actual amount that got to the receiver's account. For a completely successful payment the settled_amount should be equal to the amount else the payment status would be INCOMPLETE. For BANK_TRANSFER payments that the paid_amount is less than the charged_amount this would equally result to the settled_amount being less than the expected amount.

RULE OF THUMB

---

If the fee_bearer is set to RECEIVER then the fee would always be deducted from what ever amount was paid then what is left is send to the receiver. For example if the fee is 500 and a payment of 4000 was made then only 3500 would get to the receiver because the person receiving was set to bear the fees but if fee_bearer was set to PAYER then the fee would be added to the amount. For example if the fee is 500 and a payment of 4000 was to be made then the sender would be charged 4500 so the receiver would get 4000.