[See Part 1 here.]
In this section of my writing, I was concerned about getting the front-end and switch models aligned. If there’s model misalignment, you’re really screwed – double-bills or non-bills are sure to follow. So, I tried to get very specific here. [Some times, I’m the king of over-explainers, but experience shows it’s necessary in this situation. Don’t take anything for granted.]
-------------------------------
To make the end-to-end solution work as designed, it is important that the transaction originator and the OLS switch have their models in alignment. Most notably, the originator is obligated to provide a unique identifying number for every order. Within a single, specific order, the following must be true:
- The first Purchase attempt must contain a new order number never before used by the originator.
- If a Purchase is DECLINED, a request may be resubmitted using the same order number. Use Case: A Purchase request is submitted; the request is DECLINED for Insufficient Funds; the customer removes items from their market basket; the Purchase request is resubmitted for a smaller financial total.
- If a Purchase is APPROVED, a request may be submitted using the same order number if the previously approved transaction is first voided. Use Case: A Purchase request is submitted; the request is APPROVED but the Card Security Code (‘CSC’) does not match; the customer is given an additional attempt to provide the correct CSC; a Reversal of Purchase (Reason Code = ‘VOID’) related to the APPROVED transaction is submitted; the originating application requests and collects the new CSC; the Purchase request is resubmitted with the corrected CSC.
- If a Purchase request is formatted and sent and no response is received from OLS, a request may be submitted using the same order number if the previously attempted transaction is first reversed. Use Case: A Purchase request is submitted; no response is received within the allotted timeout period (please provide 30 seconds); a Reversal of Purchase (Reason Code = ‘TIMEOUT’) related to the original transaction is submitted; the Purchase request is resubmitted.
If the originator does not abide by these obligations, transactions with non-unique order numbers will be treated as duplicates – implying they will not go out for real-time reversal but will instead simply copy and provide the previous result on file at the switch.
[See Part 3 here.]
Recent Comments