Go Live

 

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.


Customize Hosted Experience

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.


Certification to Production

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:

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.

Develop Solution Components

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:

Certification ItemPre-Built Solution Component?Custom Solution Component?
Onboard Platform
Configure Platform
Programmatically calculate and charge fees via fee_amount
Onboard Merchants
Create Legal Entities
Invite Controllers to the WePay Merchant Center
Create Accounts
Create Payout Methods
Handle CIP/KYC Requirements
Enable Merchants*Merchants without access to the Merchant Center can be enabled with the pre-built KYC iFrame
Process Payments
Create Payment Methods
Create Payments
Follow Card Network Rules
Follow Risk Requirements
Merchant Self-Serve
Transaction history and balances
Issue full and partial refunds
Update Customer Information Program (CIP)/Know Your Customer (KYC) details*See the KYC iFrame guide, if applicable
Update Payout information
Select Payout schedule
(if multiple settlement schedules are available) via payout.currencies.USD/CAD.period
Provide any requested identification documents
Close merchant Accounts
Concede or challenge a Dispute, including uploading supporting documentation
See 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.

Launch Checklist

Before launch, WePay will certify that the following items have been sufficiently addressed in your integration:

Pre-BuiltCustom
Set Up Platform
Onboard Merchants
Process Payments
Manage Payment Operations
Notify Users
N/A

Magic Behavior

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:

"WePay-Magic-Behavior"

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.

Test KYC and 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.

Test Payments

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).

Test Payouts

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.

Test Payment Operations

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.

Test Notifications

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.