Integration Certification Program

Integrating with a new payments system is complicated. The choices you make at this early stage can have big effects on things like compliance and card decline rates. It's critical you get it right.

But it’s not always obvious what right looks like. With so many choices for how functionality be built, it can be hard to decide how it be built.

WePay wants you to have the most clarity about the process, so you can build faster. And we want you to get it right the first time, so you can avoid costly fixes later.

That's why we've created the Integration Certification Program. This consists of specific steps you must complete on your path to rolling out payments with WePay.

You must become certified to receive the rates you've negotiated. Yet that's not the main advantage of completing the certification.

We've been doing payments since 2008. In that time we've discovered best practices that allow a platform to settle faster, avoid fraud, and decline fewer good transactions. By working through your Integration Certification checklist, you’ll be building a payments engine for your platform that takes advantage of everything we’ve learned.

What follows is an example of the steps required for certification. Depending on your unique situation, some of these steps might be unnecessary. So defer to the custom plan given to you by your integration specialist in all cases.

We look forward to working with you as you complete the certification. It’s our hope that this checklist removes all uncertainty about the process, and allows you to move from integration to implementation with the peace of mind that a bulletproof payment offering provides.

Account Creation

Account creation is the process by which a merchant is registered as a WePay user, an access token for that user is captured, and a payment account is created. The access token and the account id are the fundamental pieces of information for most, if not all, subsequent operations for a merchant. Criteria for successful account creation is as follows:

    • Proper permissions: Merchants should be asked for the proper permissions in the scope parameter of the /user/register or /oauth2/authorize calls. We require that you ask for all permissions, which can be found at https://developer.wepay.com/api/api-calls/user#register.

    • Recognizable account names: The account name is used as the soft descriptor, in other words, what the payer will see on their credit card statement. For example, if the account name is “ABC Clothing Co”, it will appear as “WPY*ABC Clothing Co” on the credit card statement. Ensuring payer-recognizable account names will reduce disputes and chargebacks, thus improving the merchant and user experience.

    • Proper setting of fee schedules: Certain installations require a fee schedule id to be passed when the account is created.

    • Email confirmation: /user/send_confirmation must be called to issue the confirmation email to the user. This email contains the only secure link for the user to set their password, and change the state of a temporary access token to permanent.

    • IPN monitoring: In order to provide a good merchant experience, IPN monitoring is critical to avoid disablement and/or deletion of the account, and to insure withdrawals occur in a timely manner. Via IPNs, you will be aware of what actions your merchant’s account requires and can direct them accordingly. See https://developer.wepay.com/docs/articles/ipn for more information on IPNs.

Processing Payments

There are a number of considerations when it comes to processing payments. One or more of the following sections will be applicable for your integration. Please consult your solutions engineer as to what criteria will apply to your application certification.

  • Custom checkout (tokenization):

    • tokenization.js: To minimize unnecessary PCI Compliance requirements, use of our tokenization.js JavaScript library is required. This allows you to securely send credit card information directly to WePay for tokenization.

    • server-server tokenization: If you are PCI Compliant and credit card information being stored on or passing through your servers is a requirement of your use case, qualification for server-server tokenization is as follows:

      • Submission to WePay of current PCI Audits.
      • Inclusion of the payer’s ip address in the /credit_card/create API call.
    • Use of unique ids: Unique ids provide process handling for /checkout/create calls which might timeout. While timeouts are rare, they will occur. Use of unique ids safeguards against unwanted duplicate checkouts by providing a way to simply make the exact same call again and guarantee one and only one checkout will be created for that unique_id. Without this, you risk either not charging the payer, or charging the payer twice.

  • Card-on-file: If for any reason you will tokenize a credit card and not use it within the next few minutes, a call to /credit_card/authorize is necessary to prevent the card from expiring.

  • Delayed payouts: If you’re going to delay the payment from going to the merchant’s account for any reason, you must call /checkout/capture within 14 days of creation, otherwise the payment will be refunded.

  • Proper values for app_fee and fee_payer: There are many ways to set the app fees and fee payer values to obtain the correct disbursement of monies for a payment, some more efficient than others. Consult your solutions engineer for the most appropriate values based on your use case.

  • IPN monitoring: To insure you’re aware of and can act on checkout state changes, IPN monitoring must be implemented for checkout and pre approval objects. See https://developer.wepay.com/docs/articles/ipn for more information on IPNs.

Risk/Security

Risk and Security requirements are not only necessary to protect all participants in the system, from WePay to your platform and ultimately to your merchants and the payers, but also valuable in improving the overall experience of your platform. During project scoping, it may have been determined that one or more of the following requirements is necessary and/or valuable. Your solutions engineer will inform you of your specific responsibilities.

  • Multi-factor authentication (MFA): While MFA is an optional service you can offer to your merchants on your site, certain implementations do require MFA. Submission of PCI Audits: If you have been approved for server-server tokenization, a copy of your current PCI Audits is required.

  • Risk API Integration: Platform-specific information regarding your merchants, payers, and transactions can be passed to our risk engine and team to help us understand your merchants. Your solutions engineer will be able to help you identify those pieces of information most valuable to your implementation.

Legal



Acceptance of WePay Terms of Service and Privacy Policy 

    • WePay Terms of Service and Privacy Policy: You must obtain the electronic signature of each of your merchants on WePay’s Terms of Service and Privacy Policy. You must also make links to WePay’s Terms of Service and Privacy Policy available on your website or in your own User Agreement so that your merchants may refer to them after acceptance – including updated versions.

    • OAuth. The merchant will be presented with a checkbox next to the statement, “I have read and agree to WePay’s Terms of Service and Privacy Policy.” “Terms of Service” links to https://go.wepay.com/terms-of-service-us. “Privacy Policy” links to https://go.wepay.com/privacy-policy-us. When the merchant clicks the “Grant Access” button, the elements of the electronic signature will be passed to WePay and stored (login credentials, date/time stamp, IP address). (Note – if the merchant is located in Canada or the United Kingdom, the links will go to the WePay Terms of Service and Privacy Policy for that country, rather than the United States.)

    • User Register. Typically, you will include links to WePay’s Terms of Service and Privacy Policy in the your own User Agreement. For example, you could insert the following paragraph in your User Agreement, substituting your own name for [Platform] where it appears below:

      “[Platform] offers payments through WePay, Inc. ("WePay"), a third-party payment processor. In order for you to use WePay's payment processing services, you must register with WePay as a merchant. The WePay Terms of Service explain that process and are available here: https://go.wepay.com/terms-of-service-us.  The WePay Privacy Policy is available here:  https://go.wepay.com/privacy-policy-us. By accepting this agreement with [Platform], you agree that you have reviewed the WePay Terms of Service and Privacy Policy for the country in which you are located and agree to them. If you have questions regarding the WePay Terms of Service or Privacy Policy, please refer to the WePay website at www.wepay.com or contact WePay at https://support.wepay.com/hc/en-us.”

      After the merchant accepts your User Agreement (including the WePay Terms of Service and Privacy Policy), you may call User Register and pass the elements of the electronic signature to your User Agreement (login credentials, date/time stamp, IP address).

      You may also wish to link to WePay’s Privacy Policy from your own Privacy Policy. For example: 

      “If you elect to use the WePay payment service in conjunction with [Platform], you will enter into an agreement with WePay for use of the service and WePay’s use of your data. We encourage you to review the WePay Privacy Policy (https://go.wepay.com/privacy-policy-us), which will apply to you.”

      If you do not obtain the user’s electronic signature to your User Agreement and incorporate the WePay links described above, you will have to obtain the merchant’s electronic signature to WePay’s Terms of Service and Privacy Policy by using OAuth or an equivalent mechanism. 

    • SSO.  “Single sign-on” or “SSO” refers to an integration in which users access the WePay payment service after logging into your website without separately logging into the WePay Service. SSO is available only with WePay’s approval and subject to special agreement. If you use SSO, you will follow the guidelines for “User Register” above with respect to new users. If you make the WePay payment service available to your existing accounts through SSO, you will obtain the merchant’s electronic signature to WePay’s Terms of Service and Privacy Policy by using OAuth or an equivalent mechanism.



Access to WePay Terms of Service and Privacy Policy: 

    • OAuth. Your website must provide a link to https://go.wepay.com/terms-of-service-us labeled “WePay Terms of Service.” Depending on your website design, you can include that link at the bottom of your home page, on a “Legal” page, on a “Help Center” page, or the like. Or, you can include the link in your own User Agreement, substituting your own name for [Platform] wherever it appears below:

      “[Platform] offers payments through WePay, Inc. ("WePay"), a third-party payment processor. The WePay Terms of Service are available here: https://go.wepay.com/terms-of-service-us.  The WePay Privacy Policy is available here:  https://go.wepay.com/privacy-policy-us. If you use the WePay payment service, you agree to the WePay Terms of Service and Privacy Policy for the country in which you are located. If you have questions regarding the WePay Terms of Service or Privacy Policy, please refer to the WePay website www.wepay.com or contact WePay at https://support.wepay.com/hc/en-us".

    • User Register. If your own User Agreement contains language equivalent to that described above under “Acceptance of WePay Terms of Service and Privacy Policy/User Register”, then a link to your own User Agreement will satisfy the requirement to provide access to the WePay Terms of Service and Privacy Policy. Otherwise, you must provide a link to https://go.wepay.com/terms-of-service-us as described under “OAuth” above.

    • SSO. Depending on your implementation, you will implement the access requirements described above with respect to either OAuth or User Register.



WePay Fees: You must disclose to each user of the WePay payment service the fees that the user will pay before he or she makes the decision to use the WePay payment service. WePay’s fees may include per transaction fees, recurring fees, payer fees, and chargeback fees, depending on your implementation choices. You may choose to charge an App Fee, and you may charge fees to payers or payees. You are solely responsible for communicating all of these fees to your customers. If you charge a combined fee for your service and the WePay payment service, you may disclose the combined fee, but you must also disclose any additional fees (such as chargeback fees) that are not part of the combined fee.