Server to server integration
Full server to server integration is possible only after a merchant KYB process
It's possible to do a full on-ramp flow by using only merchant API. Here you can find how to send API requests correctly. The full workflow should look like this:
Get a list of supported countries and their payment channels.
Pick a country, payment channel, and blockchain asset. Get order limits using these values.
Get the user's KYC status and check if they need to pass a KYC process. If they need a KYC, submit the document information and check the KYC status until it's accepted.
Get the best offer , to get the quoteId, understand how much a user should pay, and what additional information is required from a user to create an order.
Create an order using the user's email, desired amount, blockchain asset, country, payment channel, additional data required from a user, and quoteId. Some orders may require verifying an OTP code sent to a user.
Getting countries, payment channels, blockchain assets and order limits
Let's get a list of supported countries , the response would be like this:
[
{
"name": "Nigeria",
"countryIsoCode": "NG",
"currencyIsoCode": "NGN",
"paymentChannels": [
{
"paymentChannel": "bank",
"description": "Bank transfer",
"requiresCarrier": false,
"carriers": []
},
{
"paymentChannel": "airtime",
"description": "Airtime",
"requiresCarrier": true,
"carriers": [
{
"id": "618e43914f57e07d255ff357",
"name": "Airtel Nigeria"
},
...
]
}
]
},
...
]We see that Nigeria is supported for on-ramp and has payment channels: bank and airtime.
Let's pick this country and bank payment channel. Let's get a list of supported blockchain assets:
We see that POLYGON USDC is supported for on-ramp; let's pick it.
Now, let's check order limits for Nigeria, bank payment channel and POLYGON USDC asset. Request query params:
Response:
So, now we understand that a user can buy from 1 to 100 POLYGON USDC and can pay from 1534 to 153376 NGN.
KYC
Let's check a user's KYC status to determine if we need to sumbit a KYC documents. Request body:
Response:
We see that there's no passedKycType field which means that the user haven't completed a KYC process in our system. Moreover, we see a list of supported documents for basic and advanced KYC.
The kycRules field indicates that we don't need a KYC for orders below $10, need a basic KYC for the $10-50(not including) range, and need an advanced KYC for the $50-100 range.
For demonstration purposes, let's at first complete the basic KYC and then the advanced one. Let's pick a basic document to submit:
We need to build an object with keys described under "requiredFields", like this:
Then we submit it using the user's email, countryIsoCode, document ID, and these fields.
Request body:
Let's check a user's KYC status again:
We see that a user passed the KYC and now has passedKycType = basic. If KYC check was still pending the response would be like the following:
Failed KYC would look like the following:
In case of rejected KYC you can try to submit a new one untill reachedKycLimit = true, thereafter, you need to contact our support team.
Now pick a document for an advanced KYC :
Everything is the same except the "images" field. It requires you to submit a photos of both sides of user's document and a user's selfie. Let's imagine that you took these photos and uploaded to the file storage under these URLs: https://cdn.com/selfie.jpg, https://cdn.com/front.jpg, https://cdn.com/back.jpg, the request to submit the KYC would look like the following:
The rest of the logic is the same
Creating an order
Let's get the best offer using parameters picked in previous steps, the order will be for 5 POLYGON USDC.
Request query:
Response:
From the response, we understand that a user should pay 7664 NGN to receive 5 POLYGON USDC, also we see that the next additional data is required from a user: buyerFirstName, buyerLastName, buyerEmail, bankCode, phoneNumber.
Let's create an order using all this data.
Request body:
Response:
Order is created, now a user must pay to the agent using the "transferInstructions" details.
Here are possible types of transfer instructions:
Manual, a user pays manually to the provided details:
STK Push, user receives a mobile carrier popup and confirms a transfer:
Redirect, user must open a specidied redirect URL and complete the transfer there. After the success they will be redirected to the URL specified during order creation.
USSD, in that case, a user must execute the provided USSD code to complete the transfer. USSD code may include a {pin} placeholder; in that case you must ask the user to provide a pin code and replace the placeholder with it before execution.
STK Push with OTP, in that case user receives an sms with an OTP code which must be sent to the confirm OTP endpoint , after that a user receives the STK Push and pays for the order
After a user sends funds to the agent, you must confirm the order.
Request body:
The order flow is finished; now you need to wait for crypto to be sent to the user's wallet. You can do that either by waiting for a webhook or by fetching the order.
Last updated