PaymentVision 4.9.12 is now available in production. The purpose of this release is to introduce one new set of functionality (Wallet Management), one new feature (Sensitive Field Masking), two new configuration options (Recurring Start Day, First Payment Day Fences) and two functional changes (Retired Card Success Handling, Bank Account Billing Address Population).
Wallet Management
Wallet Management is a new set of functionality that enables users to manage how financial accounts are both used and presented within a customer wallet. The new set of functionality includes Financial Account Storage Preference, Financial Account Deletion, and Last Used Financial Account.
Financial Account Storage Preference
Financial Account Storage Preference enables a user to specify how they would like a financial account to be stored within the system.
How it Works?
- When a financial account is added to the system, it now prompts the user if they would like the financial account to be available for use in future payments as highlighted within the screen shot below.
- If the user opts out, the financial account is immediately un-registered after it is used. If the user opts-in, the financial account remains registered
- When any PaymentVision or integrated payment application retrieves a list of financial accounts for that customer, only registered financial accounts are returned
Use Cases
- Meet the expectation of someone making a payment on-behalf of the customer (e.g., a parent or friend)
- Reduce debt collection compliance risk
Financial Account Deletion
Financial Account Deletion enables users with Manage Customer permission to remove a financial account from a customer’s wallet.
How it Works?
- User selects delete from within the Manage Customer page, as highlighted within the screen shot below
- If the account is associated with any pending payments, the system blocks the request and presents an error message
- If the account is not associated with any pending payments, the system verifies the request
- User selects okay
- System presents confirmation
How it Differs from Retire?
Unlike a financial account that has been retired, an un-registered account cannot be re-activated unless it is re-introduced into the system.
Use Case
Removing financial accounts that are no longer in active use eliminates “noise” and avoids accidental use. Sub-prime lenders have a particularly strong use case for this, where borrowers frequently pay with pre-paid cards and acquire a large collection of them during the course of a loan.
Last Used Financial Account
Last Used Financial Account presents financial accounts based on when they were last used.
How it Works?
When accepting a payment within PayAgent 2 or PayAgent Classic, a customer’s wallet is now presented in order of last use and defaults to the one that was last used.
Use Case
Reduce friction by making it easier for users to complete a payment
Functional Comparison by System
| PayAgent 2 | PayAgent Classic | Customer Manager | Customer Enrollment Website | PayAPI | |
|---|---|---|---|---|---|
| Financial Account Storage Preference | Yes | Yes | Yes | Yes | Yes |
| Financial Account Deletion | No | No | Yes | N/A | Yes |
| Last Used Financial Account | Yes | Yes | No | N/A | N/A |
Sensitive Field Masking
Sensitive Field Masking is a PaymentVision Portal and Customer Enrollment Website feature that hides sensitive data after each successive keystroke.
Target Fields
Sensitive Field Masking is now applied to the following fields as part of this release:
- Card Number
- Card Security Code
- Bank Account Number
How it Works?
When a user inputs a character into a sensitive field, the character is presented as shown within the screen shot below.
However, when the user inputs the next character into a sensitive field the previous character is masked as shown within the next screen shot.
Use Cases
- Protect against eaves dropping and harvesting of sensitive data from computer monitors
- Reduce compliance risk as it relates to PCI-DSS requirement 3.3
Retired Card Success Handling
Retired Card Success Handling is a functional change to the way in which a retired card is handled when it is the subject of a successful authorization request.
Before and After
| Before | Prior to the change, the card would remain un-retired which would cause it to be excluded from a customer’s wallet |
| After | Following the change, the card will automatically re-activate making it eligible to be included within a customer wallet |
Integrated Payment Applications
Integrated payment applications that utilize PayAPI to retrieve and populate a customer wallet can now filter out retired cards without the risk of excluding cards that are in active use.
Recurring Start Day
Recurring Start Day is a new payment plan configuration option within PayAgent 2 that enables users to start a recurring schedule on a specific day as opposed to a specific month in cases where the recurring frequency is set to weekly or biweekly. This configuration option was originally introduced to PayWeb 2 in version 1.3.32. It now works the same way in PayAgent 2.
How it Works?
When Recurring Start Day is disabled, a user specifies the start of a recurring schedule by picking a month and year.
When Recurring Start Day is enabled, a user specifies the start of a recurring schedule by picking a day.
When a min and max has been configured, the system will restrict the start day and grey out restricted days within the calendar view.
Use Case
Recurring Start Day was originally designed as a solution for an auto finance company who wanted the ability to take down payments and enroll customers in semi-monthly payment plans at the time of loan origination, where in the first installment is not due until the end of the month. While PayAgent 2 provides the ability to define a first payment independent of a semi-monthly payment plan, a month/year picker does not always provide the ability to define when the semi-monthly payment plan starts without including two installments in month one. A day picker is more appropriate under this scenario and we anticipate that this configuration option will be useful for other finance companies who want to setup both down payments and recurring payments within a single user interface.
First Payment Day Fences
First Payment Day Fences is a new payment plan configuration option within PayAgent 2 that provides the ability to place fences around the first payment date. This configuration option was originally introduced to PayWeb 2 in version 1.3.32. It now works the same way in PayAgent 2.
How it Works?
As with the Recurring Start Day, when a min and max has been configured the system will grey out restricted days within the calendar view.
Use Case
First Payment Day Fences was originally designed as a solution for an automobile finance company that wanted to restrict users from future-dating a down payment on a loan. We anticipate the new configuration option will be useful for other companies who wish to setup both down payments and recurring payments within a single user interface.
Bank Account Billing Address
Bank Account Billing Address is a functional change to the way in which the billing address is saved when the primary customer is selected as the bank account owner within the Customer Enrollment Website.
Before and After
| Before | When the primary customer was selected as the bank account owner, the billing address was not saved to the account despite being entered on the screen. |
| After | When the primary customer is selected as the bank account owner, the billing address is now saved to the account. |
