Transaction Processing
Card Transaction Processing can be configured to work with any compatible processor. Transaction processing manages a series of conditions when determining whether a transaction should be approved or not. The Auth transaction can come in as ISO20022, ISO8583 or JSON.
When a card is used by a customer to transact with a merchant, the transaction details are captured and routed through the chosen payment network to the Issuing bank in order to authorize the payment. This authorization process will validate the card credentials, score the risk level of the transaction, check against card and account limits as applicable and ultimately approve or decline the transaction. Here is a quick decision tree on how this process works when receiving an authorization request:
Decisioning Steps:
- Check the status of the Account. If the account is Restricted, Delinquent, has a Negative Current Balance, or is Pending Closed or Closed, then this transaction should be declined.
- Next, is the Card Active? If not, decline.
- Then is the transaction amount $0.00? If so this is an account inquiry or balance inquiry. Approve and return result. If the transaction is > $0.00, continue.
- The transaction is then routed through our risk-decision model to determine the transaction’s likelihood of fraud.
- Then check if this is a Funds Upload. If yes, Approve. If not, move on to next criteria. The following are now all Spend Transactions:
- Does the Account go over any Daily or Monthly spending limits? If it does decline the transaction, if not move on to the next criteria.
- Is the merchant a Gas Station (based on MCC)? If yes, ensure the Available Account Balance is greater than Automated Fuel Dispenser (AFD) minimum amount. If not, check if the Merchant Approves partial auth., and if so, the account meets the balance criteria then approve, otherwise decline.
- If it’s not a Gas Station, then approve the transaction.
Risk-Decisioning
All card transactions are evaluated to detect the likelihood of fraud during the authorization process. Visa provides a Visa Advanced Authorization score for each transaction based on the combination of global Visa data and cardholder historical data to help detect possible fraud. This powerful scoring utilizes a Visa AI platform that is based on machine learning and cloud-based risk models to improve its scoring effectiveness over time.
Along with the VAA score the transaction can be routed through 3rd-party risk engines to check the transaction against fraud mitigation rules that help capture transactions associated with learned fraud trends. Fraud rules can be added to combat current fraud trends and expired once the trends pass.
The risk-decisioning process results in a determination that the transaction should be approved and continue through the authorization process, or if the transaction should be flagged as suspected fraud. The following tag will be applied to a transaction flagged as suspected fraud with a corresponding action:
| Risk Level | Action |
|---|---|
| Pass | Transaction is approved. |
| Low-Risk | A transaction with this score is approved, but a fraud case is created to validate the transaction. |
| Medium-Risk | A transaction with this score is declined and a fraud case is created to validate the transaction. |
| High-Risk | A transaction with this score is declined and the card is immediately blocked with the status being changed to Suspected Fraud. A fraud case is created to validate the transaction. |
Validating Transactions flagged as suspicious
An SMS or e-mail to the cardholder is triggered when a transaction is flagged as suspicious. This will ask them to review the transaction details and confirm whether or not the activity is authorized.
During the Low-Risk flow, if the transaction activity is confirmed to be legitimate then they will be advised that the activity has been confirmed and no action is required. If the transaction is flagged as unauthorized then it will let them know the card has been blocked and they should contact Customer Service to dispute the transaction and request a new card.
For the Medium-Risk flow, If the cardholder validates the transaction upon receiving a notification then the transaction will be marked as confirmed and they will be advised to attempt again as needed. Our risk engine will place a marker on that transaction as approved so if it comes through again it will not be blocked. If the cardholder confirms the activity was unauthorized then the card will be immediately blocked and they will be prompted to request a new card.
In the High-Risk flow, if the cardholder validates the transaction then the card will be automatically unblocked and the transaction will be marked as confirmed. The cardholder will then be advised to attempt the transaction again. If the transaction is flagged as unauthorized then it will let them know the card is blocked and they should contact Customer Service to dispute the transaction and request a new card.
Program Configuration
For card transactions we have several fields configured that need to be updated to ensure the success of your card program. These fields are in the Metadata Config of the program.
| Metadata Field | Description | Default Values |
|---|---|---|
| Account Monthly Transaction Limit | The amount a card holder can spend monthly | $100,000 |
| ATM Daily Limit | The maximum amount a cardholder can spend at an ATM daily | $1,000.00 |
| POS Daily Limit | The maximum amount a cardholder can spend at POS daily | $3,000 |
| Credit Daily Limit | The maximum amount a cardholder can spend as credit daily | $3,000 |
| AFD minimum balance | The hold amount needed on the card balance to approve the transaction at the pump | $150 |