Test and Launch
WePay’s Clear API deals with money movement. It’s not ideal to test with live credit cards outside of staging, as each transaction will be reviewed by risk, and will be charged to your platform. As such, this page will help you figure out what and how to test.
With the Clear API product, you’re required to reach out to WePay to move to live. At minimum, you will need to sign a shared agreement between WePay and your platform.
Prior to launch, WePay will certify that your integration includes the following:
- Compliance with Card Network rules
- Compliance with WePay’s Legal requirements
- Compliance with WePay’s Risk requirements
- Compliance with CIP/KYC requirements
- Compliance with WePay’s required communication guide
You must submit your platform’s Attestation of Compliance (AoC) to WePay before you can launch. PCI compliance and other security considerations are covered in WePay’s Security Certification.
Reach out to your WePay integration team to begin the certification process.
In addition to the compliance requirements above, there are five primary components to the WePay solution which WePay will use to certify your integration. Those components and their high-level specifications are listed here:
- Onboard Platform
- Onboard Merchants
- Process Payments
- Merchant Self-Serve
- Transaction history and balances
- Issue full and partial refunds
- Update Customer Information Program (CIP)/Know Your Customer (KYC) details; see KYC iFrame guide if applicable
- Update Payout information
- Provide any requested identification documents
- Select settlement schedule (if multiple settlement schedules are available) via
- Request an account closure (handled through a manual process with WePay)
- Concede or challenge a Dispute, including providing supporting documentation; see relevant Dispute sections and Disputes Deep Dive for more context.
- Notify Users
While the Basic Integration prepares you for a baseline Clear integration, it’s important to navigate to the Cookbooks and Resources sections and prepare for more scenarios.
Before launch, WePay will certify that the following items have been sufficiently addressed in your integration:
|Set Up Platform|
|Manage Payment Operations|
Staging lets you charge Credit Cards and bank accounts, without actually capturing funds. If you want to begin testing in a live environment (or test in stage without using actual Credit Cards), we offer Magic Headers and Magic Values.
Magic Headers are key/value pairs that you place in your headers for your API requests. Magic Headers simply simulate real life responses, and ignore any information you add to API requests, like request bodies.
In order to use Magic Headers, simply add the following key to the headers of a request:
With the appropriate value found here, depending on the specific user flow being tested.
Magic Values are values used inside POST requests to simulate API behavior, such as seeing a failure use case for identity verification.
With KYC and Identity Verification, you’ll want to make sure you can simulate specific scenarios outside of the happy path use case, which is a Legal Entity and Account successfully onboarding to your platform without providing extra verification.
When you encounter these scenarios, make sure to refer back to the Onboard Merchants guide to see what information is needed.
For Payment Processing, you can test using both Magic Headers and Magic Values. If you want to test static responses, then Magic Headers are what you will use. If you want to test payments going through, with varied responses, then you will use Magic Values.
Find a full list of Magic Values here.
Let’s say you’re testing out paying via Credit Card or Payment Bank. Simply enter the values from the above table in your Payments Method call, and execute.
When testing payments, be sure to test:
- A successful payment executed one-time.
- A successful payment executed via delayed capture.
- A failed payment for various reasons.
- A successful micro deposit verification (for platforms supporting ACH).
- A failed micro deposit verification (for platforms supporting ACH).
Like Payments, when you test payouts, you have two different options. You can use Magic Headers or Magic Values. Find a full list of Magic Values here When testing payouts, be sure to do the following:
- Test a payout to a merchant’s account.
- Test a payout to a merchants account, that hasn’t enabled the capability yet.
With Payment Operations, it’s important to simulate user flows like chargebacks. We currently support the response structures you get with Magic Headers.
If you want to simulate a specific chargeback where no funds are present, use Magic Values. Find a full list of Magic Values here
Be sure to test the following:
- Test contesting a dispute.
- Test conceding a disputed.
- Test a successful refund.
Notifications are Webhooks passed to you in real time. When you test other API calls, make sure to register for Notifications. If you need area to receive Webhooks outside your own server, use a tool like: https://requestbin.fullcontact.com/.
When you register your callback_uri, simply use a URL generated by the tool above. Then, make calls to the API, and trigger notifications.
Find notification testing paths here.
Questions? Need help? Visit our support page!