Kript Pay Direct Charge
Kript Pay Direct Charge is our payment flow that allows businesses to directly charge a Flux user's account and forward payment to another Flux user's account (which could also be the business itself). This direct charge happens via a CHARGE REQUEST and FLUX TRANSFER that the user has to either manually accept for each charge or allow all charge request from a business. Here's how it works:
STEP 1: LINK USER FLUX ACCOUNT
Firstly, for a business to charge a user's Flux account the user has to link their Flux account with the business and select a permission type for the business depending on how much control the user wants the business to have. There are two types of permission types: ALLOW_ALL_DIRECT_CHARGES and REQUEST_DIRECT_CHARGE.
ALLOW_ALL_DIRECT_CHARGES would automatically accept all charge requests from a business and transfer (flux transfer) the charged amount to the specified user if the user has enough fund in their balance.
REQUEST_DIRECT_CHARGE would always send a charge request to the user for them to either accept or reject the charge. Accepting the charge request would initiate the Flux transfer of the specified amount to the specified user while rejecting the charge request does nothing but update the payment status to REJECTED and sends a webhook event.
STEP 2: CALL THE DIRECT CHARGE API
It's time to request for a direct charge, From your servers call the Request Direct Charge endpoint with the details of the payment. Here are some parameters to take note of:
| BODY PARAMS | DESCRIPTION |
|---|---|
| flux_id | This should be the Flux ID of the user to be charged. NOTE: This should only the Flux ID of a user that has linked their account with your business. On SANDBOX environment you can use Flux ID FSAND. |
| receiver_flux_id | This should be the Flux ID of the user the payment should be made to. NOTE: This can also be the Flux ID of your business, in the event that you want to receive the payment from the charged user. |
| fee_bearer | This specifies who should bear the fee for the payment between the user making the payment and the user receiving the payment. EXAMPLE: A payment of NGN 1000 and a fee of NGN 100. if fee_bearer is set to PAYER the charged user would be charged NGN 1100 and the receiver would get NGN 1000 but if set to RECEIVER the charged user would be charge NGN 1000 and the receiver would get NGN 900. |
| confirmation_time_limit | This specifies the time limit (in minutes) the charged user has to accept the charge request after which it be automatically rejected (if the user chose REQUEST_DIRECT_CHARGE permission type while linking account to your business). in the case where the user chose ALLOW_ALL_DIRECT_CHARGES. setting the confirmation_time_limit to 0 would always fail if the user does not have enough funds in their balance but if you prefer to give the user some time to fund their Flux balance then you can set this field to any amount of time in minutes (between 1 and 180). This would set the payment status to AWAITING_CONFIRMATION and send the user a Charge Request to be accepted when they have enough in their balance. |
What happens after a successful charge
In the event of a successful charge either automatically or a manual accept of the charge request from the charged user these things would happen:
- We'll send you a webhook event if you have that enabled. Learn more about webhooks and see examples here.
- We'll send an email receipt to both your customers (the charged user and the receiver).
- We'll send you an email notification.
Verify Payment
After receiving the webhook event on your server, always verify the state of the payment.
Mutiple Payment Amounts
The payment object returned from the retrieve endpoint contains 4 amount fields:
amount,charged_amount,paid_amountandsettled_amount.
- amount: The expected amount the receiving part should get.
- charged_amount: The amount that was charged, 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 (the charged user). This would always be equal to charged_amount for DIRECT_CHARGE.
- settled_amount: The actual amount that got to the receiver's account. the settled_amount may be less than the amount if you set the fee_bearer to RECEIVER, in this case the fee would be debited from the amount sent to the user (i.e amount - fee).
RULE OF THUMBIf the fee_bearer is set to RECEIVER then the fee would always be deducted from what ever amount was charged then what is left is send to the receiver. For example if the fee is 500 and a payment/charge 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/charge of 4000 was to be made then the user would be charged 4500 so the receiver would get 4000.
Updated over 2 years ago