Payment Bank Tokenization

Partners can now trigger the Pay With Bank light box whichever way they choose using WePay’s Tokenization JS library. This will behave in much the same way as the custom checkout with credit card tokenization. For payment bank account tokenization (bank_account_id), the parameters that need to be passed in are the client_id and the payer’s email. WePay’s Tokenization JS will handle everything else.

Sample Code

Step 1: Trigger the Pay With Bank light box by clicking a button.

Step 2: WePay returns a bank_account_id and passes the ID to the /checkout/create call to authorize a payment.

Your application may alternatively use the /payment_bank/persist call to confirm the bank_account_id without using it in a /checkout/create/ call. Irrespective of which call your application uses, the bank_account_id must be confirmed by your application within 30 minutes in order for the payment bank account to be tokenized.

Recurring ACH Payments Policy

In order for your application to support recurring Pay With Bank (ACH) payments, your application must support certain mandatory compliance requirements, outlined in this section. Your application must use our custom checkout APIs in order to support recurring Pay With Bank (ACH) payments (see “Custom checkout” section below for details). It is critical that your application is compliant. Violations of this policy will result in termination of your application.

Agreement to use bank account for future payments

To support the storage of payer bank account credentials and recurring use of them for payment, your application must present proper language in order to be compliant with the National Automated Clearinghouse Association (NACHA) network rules. NACHA regulations govern all bank transfers in the United States.

Display the following language before the point of payment submission: “I authorize [application name] to use my bank account for future payments. I understand that I may cancel this authorization at any time.”

Your application must store electronic proof that the payer agreed to the use of their bank account for future payments. Adequate proof constitutes the payer’s IP address and a timestamp of when they agreed to above statement. WePay or its bank may request this proof from you at any time. For additional reference, see Section 2.3 in the NACHA Operating Rules and Guidelines.

Ability to opt out of recurring payments

The NACHA rules mandate that payers who sign up for recurring bank debits must also have a way to opt out of them. These rules state that payers must be able to opt out of any recurring bank debit up to 10 calendar days in advance of the scheduled debit (for additional reference, see Subsection 2.3.2.6 Notices of Variable Debits to Consumer Accounts of the NACHA Operating Rules and Guidelines). There are two ways to satisfy this requirement:

Payer accounts: WePay strongly recommends that your application create an account for the payer if she or he wish to sign up for recurring payments. This is recommended because it provides payers with the easiest method of securely and repeatedly accessing your application to manage or opt out of recurring payments at her or his own discretion. Payers must be able to opt out of any scheduled payment 10 calendar days prior.
Notifications: WePay permits your application to manage the payer opt out requirement via notifications instead of creating payer accounts. If your application intends to implement a subscription model (automatic recurring debits to payer bank accounts), your application must send a notice 10 calendar days in advance of the debit that includes:
- the date that the impending debit will occur
- the amount of the debit
- a link to your application so the payer can opt out of or manage the recurring payment

If your application intends to implement a bank-on-file model (your application stores the payment bank credentials, but the payer must approve each payment), your application still must include a way for the payer to opt out or manage the recurring payment. However, 10 days advanced notice is not required since the bank debit will not occur without the payer’s consent.

NACHA rules for varying subscription payments

There are complex rules (Subsection 2.3.2.6 Notices of Variable Debits to Consumer Accounts) of the NACHA Operating Rules and Guidelines that are both challenging for partners to implement and for WePay to enforce. For this reason, WePay will only support subscription debits (of both fixed and variable amounts and intervals) on the condition that notice is sent 10 calendar days prior to the scheduled debit, as detailed above in the subsection “Notifications”.

Custom checkout

WePay’s embedded checkout iframe supports only one-time payments. Your application must use our custom checkout APIs in concert with our payment bank account tokenization JavaScript in order to support recurring ACH payments.

How to make a recurring ACH payment

Simply use the bank account token created through WePay’s tokenization.3.latest.js in a /checkout/create call. As of API version 2016-05-18, WePay allows re-use of the bank account token, provided that the compliance measures in the preceding sections are followed.

How to disable micro-deposits

To disable micro-deposits from the ACH verification flow, please include the avoidMicrodeposits parameter and set it to true. The avoidMicrodeposits parameter is located in the options object of your JavaScript call. This will force payers through the Instant Verification flow where they will use their online banking login credentials to verify the account as a payment method.

Errors

When tokenizing a payment bank, the JavaScript may return errors. Read more in the Bank Account Tokenization Errors section of the Errors API reference. To handle JS errors, be sure to set a second callback in the WePay.bank_account.create function.

Example

Then, a WePay error will return if an error occurs, like so:

error