Skip to main content
Vindicia Knowledge Center

Update Merchant System With Vindicia Retain Results

Update Merchant System With Vindicia Retain Results

User Story

Merchant needs to update payment transactions in Merchants backend systems with transactions retrieved from Vindicia Retain.

Prerequisites

Pre-Condition

Post-Condition

  • Payment Transactions have been updated in Merchants backend systems

Basic Scenario

  1. Transactions Retrieved from Vindicia Retain are matched to the corresponding transaction in the Merchants transaction repository.
  2. If the Payment has been successfully collected by Vindicia Retain the Subscriber services are restored in accordance with the Merchants policy.
  3. If the Payment has not been successfully collected by Vindicia Retain no action is required.

Design Approach

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)).

Sequence Diagram

Not Applicable

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

Sample code not available

Scenario Extensions

  1. Manual - Merchant elects to manually update backend systems using data retrieved from Vindicia Retain

Certification

No Certification required.

Use Case #: SEL-010

For Users

Learn More
For Users

Vindicia Subscribe Features

Learn More
Vindicia Subscribe Features
Back to Top