Merchant Status and Callbacks
Merchants are created by a Tenant and receives status changes from Ping Payments
Tenant adds new Merchants to themselves using the Ping Payments API.
Merchants have a life cycle of different statuses that changes over time. Status changes are received by the Tenant using a webhook provided by the Tenant to Ping Payments during onboarding.
New Merchants has initial status CREATED and later on APPROVED or DENIED
New Merchant will automatically receive the status CREATED.
Ping Payments will review the Merchant and set the status to either APPROVED or DENIED.
Only Merchants with status APPROVED can receive payouts.
All Merchants will go through Ping Payments KYC process and are continuously being AML-monitored by the compliance team.
| Status name | Purpose |
|---|---|
| CREATED | The initial value for new Merchants. Payments can be initiate payments to them, but any requested payout will not be processed. |
| DENIED | If a Merchant cannot receive payouts by Ping Payments, then the status will be set as DENIED. There are several reasons Ping Payments can deny a Merchant. One of them is that the organization has failed in the KYC process. A Tenant can also set a Merchant as denied by contacting our support. |
| APPROVED | A Merchant with status APPROVED is fully onboarded and can receive payouts from Ping Payments. Regular AML monitoring and KYC checks happen periodically, and if it deems necessary to halt a Merchant, then the status is being set as DENIED. |
Status changes for a Merchant are sent through a webhook
Tenants are notified by Ping Payments API when the Merchant status changes. A callback does this that Ping Payments API does to the Tenants backend system by a specific endpoint provided by the Tenant to Ping Payments during onboarding.
If a Tenant has not provided a callback endpoint for merchant status updates, then Ping Payments will not inform the Tenant of these changes. A Tenant can continuously poll the API to check the current status of a Merchant.
Polling is a useful practices
Callbacks are never guaranteed. Therefore we recommend a Tenant to either poll a Merchant or all your Merchants.
Payload-body of the Merchant webhook is a json
The following fields are included in the Merchant webhook.
| Field | Type |
|---|---|
| id | GUID as a string |
| status | Either CREATED, APPROVED or DENIED as a string |
Example of created
{
"id": "981d5bc0-f5b5-4a72-8d4e-1075552418da",
"status": "CREATED"
}
Example of denied
{
"id": "981d5bc0-f5b5-4a72-8d4e-1075552418da",
"status": "DENIED"
}
Example of approved
{
"id": "981d5bc0-f5b5-4a72-8d4e-1075552418da",
"status": "APPROVED"
}