Skip to content

Sandbox Tests

There are specific customer property values in the sandbox that will trigger set KYC/KYB outcomes. These values must be used when initializing the test customer with a /customer/init request, before sending an /akepa/identification request. Follow the given request workflow order in order to trigger the desired outcome.

For example, to trigger a "waiting_review" outcome for an individual customer (or a businessRepresentative), take the following request workflow steps as outlined in the table below:

  • Initialize an individual customer with the lastName: "WaitReview" with a /customer/init request. (For KYB, initialize a business customer containing a businessRepresentative with the last name "WaitReview".)
  • Use the customerId issued in the /customer/init response to create a KYC/KYB application with an /akepa/identification request. At this point, the KYC status will be "pending_step_up". (For KYB, the "pending_step_up" status will be attached to the businessRepresentative entity.)
  • Generate a documentId for the front of the individual customer's (or businessRepresentative's) Driver's License using an /akepa/document/generate request. Do the same for the back of the individual customer's Driver's License.
  • Use the front documentId generated from the /akepa/document/generate request to upload the front Driver's License image with an /akepa/document/upload/:documentId request. Do the same for the back Driver's License image using the back documentId.
  • Make an /akepa/update request to attach the uploaded documents to the customer's KYC application. This will result in the desired "waiting_review" KYC outcome status.
  • Contact PayGears to let us know that a manual review is required for the test application. Provide the customerId, applicationId, and indicate whether the desired outcome for the test is "Approved" or "Denied". We recommend doing one test for each of these outcomes.
  • Once a PayGears representative manually moves the application into the desired outcome status, you will receive a webhook notifying you of the status change since it occurred asynchronously.

You can test these outcomes using the following values:

Customer Type Customer Property Value KYC Outcome Request Workflow Order
individual lastName "Denied" An individual customer last name of "Denied" will trigger a "Denied" KYC outcome [/customer/init, /akepa/identification]
individual lastName "WaitReview" An individual customer last name of "WaitReview" will trigger a "waiting_review" KYC outcome [/customer/init, /akepa/identification, /akepa/document/generate for front of identification document, /akepa/document/generate for back of identification document, /akepa/document/upload/:documentId for front of identification document, /akepa/document/upload/:documentId for back of identification document, /akepa/update]
business businessRepresentative[#].lastName "Denied" A business representative with a last name of "Denied" will trigger an overall "Denied" KYB outcome (even if the business entity itself passes KYB) [/customer/init, /akepa/identification]
business businessRepresentative[#].lastName "WaitReview" A business representative with a last name of "WaitReview" will trigger an overall "waiting_review" KYB outcome (even if the business entity itself passes KYB) [/customer/init, /akepa/identification, /akepa/document/generate for front of business representative's identification document, /akepa/document/generate for back of business representative's identification document, /akepa/document/upload/:documentId for front of business representative's identification document, /akepa/document/upload/:documentId for back of business representative's identification document, /akepa/update]
business postalCode for PRIMARY business address "00000" A business representative with a PRIMARY business address postalCode of "00000" will trigger an overall "waiting_review" KYB outcome (even if the business representative(s) pass KYB) [/customer/init, /akepa/identification]