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. What happens if my vendor updates their registration?
When a vendor updates their routing or bank account information in PaymentWorks, a new token will automatically be generated to reflect the new banking details. Once this update is reviewed and approved, it is critical that the new token be updated in the payer's ERP system. This ensures that future payment files reference the correct token for the vendor's current bank account.
15. If I enter the incorrect token, will my payment be rejected?
Not necessarily. It is essential that payers update their ERP systems with the correct and current token for each vendor. A token will only be rejected if the submitted token does not exist in the PaymentWorks system for that specific payer. Payers cannot submit tokens that belong to other payers, as tokens are payer-specific.
If a vendor updates their banking information and a new token is generated, the old token remains in the PaymentWorks system for that payer. If the payer continues submitting an older token, the payment will process to the vendor's prior bank account.
PaymentWorks does not provide an alert or warning at payment time if a payer submits an outdated token when a newer token exists. It is the payer's responsibility to ensure their ERP is updated with the latest token so that payments are routed to the correct vendor account.
16. 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.
17. 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.
18. What is the tokenization backfill report?
The Tokenization Backfill Report provides key banking and tokenization details to support payers transitioning between tokenized and non-tokenized banking information. It includes:
- ERP Vendor ID
- Site Code
- Bank Account Routing Number
- Bank Account Number
- PaymentWorks Tokenized Routing Number
- PaymentWorks Token
The report is used for:
- Supplying actual banking details for payers who no longer want to use tokenization.
- Providing tokenized banking data for payers adopting tokenization instead of storing actual banking information.
Here's a backfill report sample:
