Build Payment Support Tools
Clear platforms own the full user experience, including the first tier of support for payers and merchants. The WePay API enables you to build tooling for your support agents, such that you can quickly triage and resolve payment issues that may arise.
We require partners integrating the full Clear solution to own Tier 1 support. There are specific items which your team must be prepared to handle for end users, and the basic requirements and how-to's are outlined in this development guide, for both building it yourself, or leveraging the Partner Center.
These tools should be integrated into any existing tooling that your support team regularly uses to assist your user base with support questions from payers and merchants.
This guide will walk through how to build support tooling required for Clear integrations via our API, or how to use the Partner Center to achieve the same results.
Understand Requirements
Support tool components go hand in hand with merchant self-serve features. At its core, support tooling empowers your support team in assisting merchants with payments-related questions and tasks. Conversely, merchant self-serve features (listed here under item #4) empower merchants in getting the information they need without support intervention. As such, some requirements for your support tools can be met with the functionality provided in your merchant experience. All applicable items are listed under Conditionally Required Components. Additionally, the Partner Center can be leveraged to fulfill some support tooling components. Applicable requirements for which the Partner Center can be leveraged will be noted and outlined in the “Partner Center Method” sections.Recommendations on building your support tool to complement Partner Center features will be provided as appropriate.
Required Components
Component | Supportability Context | Custom Method | Partner Center Method |
---|---|---|---|
Update merchant email addresses | Merchants may unexpectedly lose access to the email address, and your support team must be prepared to help them regain access to their account. |
|
|
View Payouts | Provide statuses and any failure/pending reasons to assist merchants with receiving Payouts. |
|
|
View Payments | Provide statuses and any failure/pending reasons to assist merchants and/or payers with processing Payments. |
|
|
Access Legal Entity Verifications | Guide merchants as to the kind of information and/or documentation to provide. Provide merchants with the standard list of acceptable documents, then contact our support if more detail is needed. |
|
|
Access Account Capabilities | There are strict regulatory requirements concerning KYC/CIP verification and account balances, and we communicate these by way of Account Capabilities and related current and upcoming issues. Your support team needs to guide merchants on required information, documentation, and deadlines. |
|
|
Generate merchant reports | Oftentimes, merchants may request assistance in reconciling their account. In order to offer this support, your team will need the ability to generate the same report the merchant receives. In addition, platforms which support Merchant IC+ should provide merchant billing statements to their support team. |
|
|
Conditionally Required Components
These components are vital to supporting payments on your platform. That said, if these functions are provided in your merchant self-serve features, then they are not required in your support tool.
Component | Supportability Context | Custom Method | Partner Center Method |
---|---|---|---|
Issue refunds | Situations may arise where a merchant is unable to issue a refund via the self-serve experience. Thus, we strongly recommend including this component in your support tool. |
|
|
Update Payout periods | Due to our review process for payments and payouts, merchants may want a payout sooner than their next scheduled payout if they are on a weekly or monthly schedule. To provide the best customer experience, enable your team to make this change for merchants. |
|
|
Prior to your launch with WePay, your platform will need to demonstrate that the above requirements are met.
You'll demonstrate your merchant self-serve first, at which point the requirements for your support tool will be determined on the above criteria.
Design Considerations
Gate Access
Many support teams have tiers based on experience, and more responsibility is granted the more experience a support team member has. As such, we recommend gating payment-related support tools as a security measure for your merchants and payers, and for your platform.
For instance, a newer member of a support team may not be familiar enough with your custom tools and policies to successfully look up the correct merchant account and update their payout period.
Mask WePay IDs
WePay API IDs are not intended for end-user consumption, though they are required in order to escalate support issues to WePay. As such, we recommend leveraging thereference_id
parameter in the API wherever available (Accounts, Legal Entities, controller, additional representatives, payments, etc).This will allow you to display your own IDs for transactions and such to end users, and to refer back to the WePay API object on the back end.
Additionally, your support team will need access to the WePay API IDs on occasion, but these IDs should be displayed such that any possible confusion with external-facing IDs is minimized. For instance, consider implementing a button in your support tool to fetch the WePay API ID of a given object.
For example, display your own IDs for Payments (which may also be used forreference_id
in the WePay API):And reveal the WePay API ID on-click: