To get started integrating the WePay API, please be sure to register in our stage environment. All testing and development should be done here, as we cannot process test payments in our production environment. Stage is functionally a mirror of production, so no surprises will pop up once you migrate to production and go live.
We recommend testing the payment experience end to end by creating accounts, creating checkouts, and facilitating payments via the API. Please note that your app’s account ID should only be used to collect fees, not full payments.
Instant Payment Notifications (IPNs) are considered a key component of a successful integration. WePay will send you updates regarding your users, accounts, and payments via IPNs. We strongly recommend including a callback_uri on every API call with the callback_uri parameter.
You can learn more about WePay IPNs in our Developer Documentation article.
Account Names and Soft Descriptors
The account name will appear on payers’ statements, prefixed by WPY*. To avoid refund requests and recognition chargebacks, please be sure to descriptive, succinct account names.
WePay’s intended use case involves you, the Platform, connecting Payers (individuals like donors or buyers making a payment) to Payees (individuals receiving funds, like merchants or fundraisers). In this model, the Platform receives a portion of each payment, not to exceed 20% of the total transaction.
The Platform is responsible for specifying the amount to be received as a fee through use of our fee structure during checkout. You can specify who pays the app_fee by setting the fee_payer parameter in the fee structure. There are four separate fee_payer values, as seen in our API Reference for fee. The fee_payer parameter is not required, and by default all fees will be charged to the payer.
Throttle Limits & Batching Requests
In an effort to protect all of our partners from poor performance, we will throttle your API calls once you hit/exceed 30 API calls every 10 seconds. Even our highest traffic partners rarely need their limits modified, but we do realize that exceptions must be made under rare circumstances. If you feel you need a higher limit after testing reasonable use cases and implementing batch requests, we're happy to evaluate your specific situation.
- Research and Development
- Create your development application here.
- Determine any settings you need (tokenization, colors, image, etc).
- Email email@example.com with your stage client ID for any administrative settings (supported countries).
- Review any necessary PCI Compliance requirements. A good resource to get started can be found here.
- Determine how you want to configure your app fee settings.
- Migrate to Production
- Before continuing, if you’re using a custom form for checkout, we would recommend that you review any necessary PCI Compliance requirements. If you are using embedded checkout, you’ll need to fill out the simplest form, the SAQ-A.
- If you have not already, create an app account in production.
- Add your Basic Account Verification information in the application account’s Trust Center. This is found by clicking the gear of the sub account where the application is nested. Adding this will help facilitate your withdrawals after you have begun collecting funds.
- At this point, if you are planning on tokenizing credit card information, you should apply for it tokenization in your production dashboard.
- If you have had the API Support Team make administrative adjustments to your stage app, provide your stage and production client IDs and request that all settings from stage be migrated to production.
- Perform a final check on your app fee settings—the per-transaction fee that you will collect.
- Perform a final check on your scope settings (as to what you will allow your users access to), either in OAuth2 or with the /user/register call.
- Switch the endpoints of your application from the stage values to the production values. More information for this can be found in our documentation on Endpoints.