Compliance (ToS & KYC/KYB)

Terms of Service

Customers will need to agree to our Terms of Service (ToS). The preferred option for handling this is to incorporate our entire ToS into your own, ensuring that the end user agrees to the ToS before using the service.

KYC / KYB

Any Customer that is created in Walapay must go through the Know-Your-Customer (KYC) or Know-Your-Business (KYB) process. KYC/KYB verification involves collecting key information (address, full legal name, ID information, etc.) and documents (passport, proof of address, etc.) about the Customer being created. This information allows Walapay to determine if an Customer is valid (ie. they are who they say they are) and ensures you, as a developer, are staying compliant with local laws and regulations related to money-laundering (AML).

Status Progression

📘

Expected Time-to-Approval

In sandbox, customers will be automatically marked as APPROVED (this may take a few seconds). In production, individual customers are usually approved within a few seconds (unless they are from a high-risk country, in which case it can take a day) and business customers can take 2-3 days (unless they are from a high-risk country, in which case it can take a week).

Once submitted, KYC/KYB statuses can progress in the following ways:

1. SUBMITTED→APPROVED

   • This is our happy path (KYC only). The customer information was submitted, and quickly passed via automated checks within seconds
   • In sandbox, customers always follow this path

2. SUBMITTED→UNDER_REVIEW → APPROVED/REJECTED

   • If certain aspects of the entity data seem incorrect or have missing information, the Walapay compliance team may need to manually review the customer's information
   • All business customers will go through this flow

3. SUBMITTED→REJECTED

   • In some cases, an entity may be immediately rejected due to invalid information (e.g., incorrect tax identification numbers)

Sandbox Testing

By default, sandbox customers of type INDIVIDUAL are automatically approved. However, if you want to test a rejected customer, use this data for an customer of type INDIVIDUAL:

Handling UNDER_REVIEW and REJECTED

If the Customers API and KYC Links return that the customer's KYC is rejected or under review, there are two fields shared to explain the reasoning:

• Developer Reason is meant to be used by developers for internal purposes only. This field can contain sensitive information intended for only the developer and is provided to help with troubleshooting potential issues or protecting against potential abuse.
• Reason can be shared by a developer directly with their customers.

{
   ...customer
  submissionIssues: [
    {
      "developerReason": "Document not recognized.",
      "reason": "The type of ID you provided is not supported. Please try a different form of        	             government-issued ID.",
    },
    {
      "developerReason": "Document not readable.",
      "reason": "We couldn't read your ID clearly. Please upload a clearer photo.",
    }
  ],
}

When a customer is rejected, there are two ways to update the customer with the correct information:

1. Use the KYC link that is available on the customer object to re-submit their form with the proper data
2. Use the PUT /customers/:id endpoint to update the customer object with the proper data

Either of the above solutions will re-trigger a compliance check on the user you have submitted.

Developer Reasons and Reasons