Risk Certification
WePay provides integrated payment processing APIs in addition to risk and compliance overhead management. As a partner platform to WePay, following these certifications will enable WePay to make the best risk decisions for you and your merchants.
rBits
An rBit, or Risk Bit, is a piece of information that a platform can send to WePay through the rBits API, providing more detail about a merchant or a specific transaction.
WePay tailors its policies and procedures to the needs of WePay's partners and the risk profiles of their merchants. WePay risk processing considers information received from platform partners in evaluating and mitigating payment and account-level risk. WePay's rBits API enables smooth and secure sharing of contextual data such as rBits. This data may help increase conversion rates and reduce risk friction for both Payers and Merchants.
WePay's models are continuously learning to stop rapidly changing fraud patterns. Here's how our numbers stack up against the industry:
Industry Average | WePay Average | |
---|---|---|
Online Fraud | 0.90% | <0.10% |
Manual Review Rate | 7-8% | 1% |
Decline Rate | 2.9% | 0.37% |
Account-level rBit data help with improving the accuracy of WePay's risk solution, reducing manual review times, and reducing documentation requests from Merchants.
Payment-level rBit data provide granular detail about the transaction, again, helping to improve the accuracy of WePay's risk solutions and avoiding false positives. Contextual data about a payment help WePay's Risk team verify that the payment adheres to WePay's Terms of Service and compliance requirements. The inclusion of payment-level rBits reduces the frequency and duration of manually reviewed payments as well as allows WePay's Risk team to accurately action a payment.
Note
Any payments or settlement in risk review is subject to a delay of funds up to 1-2 business days.
The following standard rBits for SMB and Fundraising platforms outline the kind of data your platform should sent us in rBits. These standard rBits typically use the same rBit types, and the text points to the specific information that should be provided.
Standard rBits for SMB Platforms
**Account-level rBits**
Information | rBit parameter |
---|---|
Business Information: | |
Business name | business_name.name |
Principal name | person.name.first person.name.last person.role : employee |
Business address | address.address_type address.origin_address |
Business description | business_description.description |
Business phone number | phone.country_code phone.phone_number phone.phone_type : business |
Industry | industry_code.code industry_code.code_type |
Relationship Information | |
Sign-up date | external_account.is_partner_account external_account.account_type external_account.create_time external_account.connections external_account.uri |
Subscription plan name | partner_service.service_name |
Subscription monthly amount | partner_service.service_monthly_cost |
Payment-level rBits
Information | rBit parameter |
---|---|
Transaction Line-Item Details | |
Service item description | transaction_details.itemized_receipt.description |
Price | transaction_details.itemized_receipt.item_price |
Quantity | transaction_details.itemized_receipt.quantity |
Sub-total amount | transaction_details.itemized_receipt.amount |
SMB terms of service text | transaction_details.terms_text |
Additional notes | transaction_details.note |
Client/Payer Invoice Information | |
Payer full name | person.name.first person.name.last person.role : other_third_party |
Service address | transaction_details.service_address |
Payer phone number | phone.country_code phone.phone_number phone.phone_type : personal OR mobile |
Standard rBits for Fundraising Platforms
**Account-level rBits**
Information | rBit parameter |
---|---|
Campaign Organizer Information | |
Campaign organizer name | person.name.first person.name.last person.role : fundraiser |
Campaign organizer social media links | external_account.account_type external_account.uri external_account.is_partner_account : false external_account.connections |
Campaign page URL | fundraisng_event.uri fundraising_event.name |
Non-profit name | business_name.name |
Non-profit description | business_description.description |
Non-profit address | address.origin_address address.address_type : headquarters OR satellite |
Relationship Information | |
Sign-up date | external_account.is_partner_account external_account.account_type external_account.create_time |
Subscription plan name | partner_service.service_name |
Subscription monthly amount | partner_service.service_monthly_cost |
Payment-level rBits
Information | rBit parameter |
---|---|
Transaction Line-Item Details | If the platform allows donors to leave a comment with their donation, then the platform can pass the transactions_details rBit at the checkout level. |
Service item description | transaction_details.itemized_receipt.description |
Price | transaction_details.itemized_receipt.item_price |
Quantity | transaction_details.itemized_receipt.quantity |
Sub-total amount | transaction_details.itemized_receipt.amount |
SMB terms of service text | transaction_details.terms_text |
Additional notes | transaction_details.note |
Campaign Organizer Information | |
Campaign page URL | fundraising_event.uri fundraising_event.name fundraising_event.description |
Donor Information | If an account runs multiple campaigns through one account, then the platform must pass the fundraising_event rBit at the checkout level. |
Payer full name | person.name.first person.name.last person.role : other_third_party |
Payer address | transaction_details.shipping_address.line1 transaction_details.shipping_address.line2 transaction_details.shipping_address.city transaction_details.shipping_address.line2 transaction_details.shipping_address.postal_code transaction_details.shipping_address.country |
Payer social media links | external_account.account_type external_account.uri external_account.is_partner_account : false external_account.connections |
Risk Headers
The WePay API accepts Risk HTTP headers on every request which provide WePay with risk-related information about that request. While optional, partners are strongly encouraged to provide this data when possible to improve the accuracy in WePay's risk solutions and to help streamline decisioning.
The combination of rBit data and Risk Header information equips WePay's Risk team with information necessary for review and underwriting purposes. As with rBits, Risk Header data helps to reduce the frequency and duration of manually reviewed payments, thereby increasing fund availability.
WePay's Risk Engine keys off of Risk Header data to help with more accurate and effective decisioning. Some of this information is passed to WePay on POST /accounts
and POST /payments
. Having said that, passing that data as an rBit can help to improve the accuracy of WePay's risk solution, reduce manual review times, and reduce requests for additional documentation.
Read more about Risk Headers.
There are two types of risk-related request headers:
Client IP
This HTTP header value should be the public IP address of the client whom the API call is made on behalf of. For example, if a partner is making a /credit_card/create call, this would be the IP address of the user who triggered the API request on the partner's system
WePay Risk Token
This HTTP header value should be the risk token UUID generated by the WePay JavaScript library on the webpage where the API request on the platform's system is triggered.
Note
The Risk Token header is required when the tokenization JS library is not being used.
Settlement Limits
Settlement Limits are funds that are not available for the merchant to settle until a given period of time passes. WePay implements a settlement limit policy to protect the company and the merchant against account debits associated with refunds, chargebacks and disputes.
Weekly Settlement Limit
WePay's current settlement product begins with a platform-level default settlement limit value that takes several factors into consideration. These factors include the platform's average payment amount, MCCs serviced on the platform, platform-wide refund and chargeback rates, and several other variables.
The Weekly Settlement Limit is comprised of two components; a dollar value and a rolling time value. A Settlement limit of $500/1week indicates that a Merchant can settle up to $500 within a 7-day time period and all additional payments processed within that time period will be available for withdrawal after 7 days.
To illustrate, this table shows how the dollar value and rolling time value interact with a custom weekly settlement limit of $100,000.00:
Day | Amount Processed | Amount Available for Settlement (Payout) |
---|---|---|
1 (start of week 1) | $120,000.00 | $100,000.00 |
2 | $150,000.00 | $0.00 |
3 | $170,000.00 | $0.00 |
4 | $100,000.00 | $0.00 |
5 | $110,000.00 | $0.00 |
6 | $120,000.00 | $0.00 |
7 | $200,000.00 | $0.00 |
8 (start of week 2) | $50,000.00 | $70,000.00 ($20,000.00 from Day 1 + $50,000.00 from current day) |
9 | $30,000.00 | $180,000.00 ($150,000.00 from Day 2 + $30,000.00 from current day) |
10 | $20,000.00 | $190,000.00 ($170,000.00 from Day 3 + $20,000.00 from current day) |
11 | $70,000.00 | $100,000.00 ($100,000.00 from Day 4 + $0.00 from current day since the weekly settlement limit has been reached) |
12 | $100,000.00 | $110,000.00 ($110,000.00 from Day 5 + $0.00 from current day) |
13 | $130,000.00 | $120,000.00 ($120,000.00 from Day 6 + $0.00 from current day) |
14 | $120,000.00 | $200,000.00 ($200,000.00 from Day 7 + $0.00 from current day) |
Exceptions
Any deviations or exceptions to above-established policy and procedure need approval from WePay. Please reach out to your Account Manager or api@wepay.com for any exception proposals.