This FAQ provides an overview of PaymentWorks’ bank account tokenization feature, explaining the process of tokenizing domestic bank accounts within the PaymentWorks system. It also highlights the benefits of this optional security feature for customers utilizing PaymentWorks' ACH Payments solution.
Frequently Asked Questions
1. What is Tokenization?
Tokenization is a feature that replaces sensitive bank account details (e.g., routing and account numbers) with unique tokens in the PaymentWorks ACH Payments solution. When enabled, customers receive these tokens instead of the actual account information for processing payments to domestic ACH accounts.
2. How does tokenization work?
Tokens serve as substitutes for bank account numbers. When you submit your domestic ACH payment file, PaymentWorks processes these tokens. PaymentWorks then "de-tokenizes" the data, providing your bank with the correct payment instructions linked to the original bank account.
3. What are the benefits of using tokenization?
Tokenization offers several key benefits, including:
- Reducing the risk of fraud
- Deterring hacking and minimizing the impact of data breaches
- Enhancing transaction security
4. Is tokenization required?
No, tokenization is an optional feature.
5. What is the format of a bank account token?
A bank account token is a 16-digit numeric value.
6. What is the format of the routing number token?
When sending a tokenized payment file to PaymentWorks, you must use the routing number 222222226 alongside the token. This specific routing number, paired with the token, signals that tokenization is being used for the vendor’s bank account.
7. If a Payer terminates their relationship with PaymentWorks, can they still access domestic ACH banking information?
Yes, if a payer discontinues their relationship with PaymentWorks, they can retrieve the domestic ACH banking details for their vendors.
8. Do all transactions in a payment file need to be tokenized?
No, payment files can contain both tokenized and non-tokenized transactions. Non-tokenized transactions will be processed normally without requiring "de-tokenization."
9. What if our organization doesn’t store banking data in our ERP?
For customers who do not store banking data in their ERP, tokenization is necessary. You must store the tokenized routing and account numbers to generate payment files for processing through PaymentWorks.
10. Can we test tokenization in our sandbox environment?
Yes, testing tokenization in a sandbox environment is encouraged for all customers planning to use the feature.
11. Is testing tokenization mandatory?
No, testing is not required, but it is highly recommended to ensure smooth implementation.
12. Can a Payer access non-tokenized banking information?
Yes, permissions can be configured within PaymentWorks to allow designated team members to access non-tokenized banking details.
13. When is a token first generated?
A token is created when the following conditions are met:
- Payments are enabled for the Payer
- Tokenization is enabled for the Payer
- The bank account is a domestic ACH account
Once these conditions are satisfied, tokenization will occur in the following scenarios:
- A domestic ACH account is submitted with a New Vendor Registration (NVR)
- A new bank account is created and linked to a Payer
- An existing bank account is connected to a remittance address already associated with a Payer
14. Does tokenization need to be enabled at the time of payment implementation, or can it be added later?
Tokenization can be enabled at any time by submitting a Change Request. The Payment Operations Team can run a script to backfill tokens for any vendors with domestic banking information. A backfill report can be provided via secure transfer for upload to your organization’s ERP.
15. Can tokenization be disabled?
Yes, if you choose to disable tokenization, PaymentWorks will provide your vendors' banking information if you decide to discontinue using the feature.