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 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.
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):
- 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 ensure 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 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.
- PCI-DSS requirements: The credit card networks require platforms to complete a Self-Assessment Questionnaire with respect to PCI-DSS compliance. In addition, if you have been approved for server-server tokenization, a copy of the PCI-DSS Attestation of Compliance relating to your current audit 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.
- 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.