WePay

Payment Bank Tokenization

Partners can now trigger the Pay With Bank popup whichever way they choose using WePay's tokenization.v2.js. 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.v2.js will handle everything else.

Sample Code

Step 1: Trigger the Pay With Bank popup by clicking a button

<input type="button" id="bank_popup" value="Test me!">
<script type="text/javascript" src="https://static.wepay.com/js/tokenization.v2.js"></script>

<script type="text/javascript">
    (function() {
        WePay.set_endpoint("stage"); // change this to "production" when live

        // Shortcuts
        var d = document;
        d.id = d.getElementById,
            valueById = function(id) {
                return d.id(id).value;	
            };

        // For those not using DOM libraries
        var addEvent = function(e,v,f) {
            if (!!window.attachEvent) { e.attachEvent('on' + v, f); }
            else {e.addEventListener(v,f, false); }
        };

        // Attach the event to the DOM
        addEvent(d.id('bank_popup'), 'click', function() {
            response = WePay.bank_account.create({
                'client_id': 12345, // Your client_id goes here
                'email':"test@example.com"
            }, function(data){
                if(data.error) {
                    console.log(data);
                    // handle error response
                    } else {
                    // call your own app's API to save the token inside the data;
                    // show a success page
                    }
                }
            );
        });
    })();
</script>

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.

# WePay Python SDK ‐http://git.io/v7Y1jA
from wepay import WePay

# application settings
account_id = 123456789 
access_token = 'STAGE_8a19aff55b85a436dad5cd1386db1999437facb5914b494f4da5f206a56a5d20' 
production = False

# bank account id to charge
bank_account_id = 123456789

# set production to True for live environments
wepay = WePay(production, access_token)

# charge the bank account
response = wepay.call('/checkout/create', {
    'account_id': account_id,
    'amount': '25.50',
    'short_description': 'A vacation home rental',
    'type': 'GOODS', 
    'payment_method': {
        'type': 'payment_bank',
        'payment_bank': {
            'id': 20000061
        }
    }
})

# display the response
print response

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:

  1. The date that the impending debit will occur,
  2. the amount of the debit, and
  3. a link to your application so that 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.v2.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.