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.
Start by going to the Partner Center. After selecting Clear in the product selection, navigate to the “Merchant Branding” feature to upload your partner logo and select colors to match the look and feel of your platform.
After, select the thumbnail image to open a static preview to see how your branding will alter the Merchant Center. Once sufficient, select “Apply to Stage”, which will apply your customizations to your stage environment. If your application is approved for production your customizations will apply to both stage and production. If desired, log into your Merchant Center via a merchant account to see your branding.
Clear with Hosted Experience also allows you to customize your mobile and email branding. Note, the color scheme applied to your desktop customization automatically applies to your mobile customization, which can be changed if desired. Mobile and email logos can be customized to match the look and feel of your platform.
Once you're done configuring the look and feel of the experiences, you'll onboard the controller.
With the Clear API product, you're required to reach out to WePay to move to Production. 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:
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 production 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.