Update Merchant System With Vindicia Retain Results
Merchant needs to update payment transactions in Merchants backend systems with transactions retrieved from Vindicia Retain.
- Transactions have been retrieved from Vindicia Retain (see Retrieve Results of Vindicia Retain Processing (SEL-002))
- Payment Transactions have been updated in Merchants backend systems
- Transactions Retrieved from Vindicia Retain are matched to the corresponding transaction in the Merchants transaction repository.
- If the Payment has been successfully collected by Vindicia Retain the Subscriber services are restored in accordance with the Merchants policy.
- If the Payment has not been successfully collected by Vindicia Retain no action is required.
Use the data resulting from Vindicia Retain processing (see Retrieve Results of Vindicia Retain Processing (SEL-002)) to identifies whether a failed transaction has been recovered by Vindicia Retain or not. Data fields used in Vindicia Retain processing are described in the Use Case Implementation section of the this Use Case.
The merchant system should use the data from Vindicia Retain processing to update the Subscriber status:
- When a failed transaction is recovered by Vindicia Retain, the merchant system should update the subscriber status to reflect the payment and leave the subscriber entitled with full access to the service.
- When a failed transaction is not recovered by Vindicia Retain, the merchant system should update the subscriber status to continue to reflect the payment as failed, and identify follow-up steps with the Subscriber resulting from failure of payment.
For recovered transactions, the merchant finance department may want to identify the transactions which were settled in the payment processor portal for reconciliation of the revenue received (see Reconcile Recovered Transactions (SEL-009)).
Use Case Implementation
The following fields are always returned with the results of Vindicia Retain processing:
1. The authorization response code received from the most recent Failed authorization (i.e. decline code such as 302, 530, or other).
2. The time of the final status determined by Vindicia Retain.
3. The amount of the transaction recovered or attempted by Vindicia Retain (equal to the failed transaction amount).
4. The final status of the transaction determined by Vindicia Retain. When the failed transaction is recovered, the status will be Captured.
5. The unique identifier for the failed transaction, as provided to Vindicia Retain when processing was requested.
6. A unique identifier assigned by Vindicia Retain to the final transaction attempt made by Vindicia Retain, which resulted in the status returned.
This identifier is sent by Vindicia Retain to the payment processor in the Order ID/Number field when the Vindicia Retain Transaction is processed. The merchant can use this identifier as a search value to search for the recovered transaction in the payment processor portal (see Reconcile Recovered Transactions (SEL-009)).
7. If a refund was performed, a unique identifier assigned by Vindicia Retain to the refund (see Refund Vindicia Retain Transactions (SEL-005)).
8. The AVS (Address Verification) result for the Billing Address received by Vindicia Retain for the final attempt.
Sample code not available
- Manual - Merchant elects to manually update backend systems using data retrieved from Vindicia Retain
No Certification required.
|Use Case #: SEL-010|