Integrating web auths into our switch, Part 1

We recently created a Web Authorization gateway to talk to our in-place payment switch.  Here’s part one of what I wrote to the writers of the customer-facing application on how to integrate...

------------------------

The OLS.Switch implementation is a host-centric model:

1. The originator sends a purchase (‘sale’) authorization request.
2. The originator does not send any follow-up ‘capture’ transaction.
3. Once every 24 hours (just past midnight Eastern time), OLS extracts and formats for file-based settlement all approved, non-reversed (see next) financial transactions.
4. Should the originator wish to not settle a specific authorization request, they are obligated to send a follow-up reversal transaction. Reversals are either voids or timeouts.

The originator should allow 30 seconds for a response. [OLS allows up to 28 seconds for each of the outbound gateways and authorizers to respond to external requests.]

Reversals can only be executed within the same business day cycle.

Subsequently, the originator can also elect to perform a Refund (a.k.a., Return). [OLS can support a lengthy period between original and refund.]

The specific transaction set covered by the interface is as follows:

Purchase (‘Sale’) – Requests payment authorization from the cardholder’s issuing bank or authorizer.

Timeout Reversal of Purchase – For any purchase request to the OLS application that is not responded to within the timeout period, the originator is obligated to send a timeout reversal.

The originator provides no cardholder information on the reversal. However, the reversal must contain the same order id as the original purchase request.

Note that unlike purchases and refunds, the switch does not approve reversals, it simply ‘accepts’ them (assuming that the requests are well-formed and the switch is functioning properly). This policy is a protective measure to reflect the fact that reversals often emanate from originators’ store-and-forward (‘SAF’) queues. SAF-ed transactions must always be accepted; else, endless loops between originator and switch could result.

Void of Purchase – The void is similar to a reversal in effect but the reason differs. Voids are employed in the following situations:

1. The customer elected to cancel the transaction.
2. The transaction was approved, but the originator was also notified that the Card Security Code (’CSC’) did not match. If the business rule is to request that the customer re-enter the CSC for retry, the previous attempt(s) must be voided first. [It’s assumed that in all transactions comprising a sequence like this, those successive attempts would use the same order number; therefore, void-before-retry is a must.]
3. The transaction was approved, but the originator was also notified that the postal code supplied in the request did not match. [Note: If the street address was supplied, other response values can notify of partial failures.] If the business rule is to request that the customer re-enter the address information for retry, the previous attempt must be voided first (for the same reason as noted above.

As with the timeout reversal, the request does not include cardholder information and must contain the same order id as the original purchase request.

Like the Timeout Reversals, the switch always ‘accepts’ voids

Refund (a.k.a., ‘Return’) – The refund requests that the card issuer place funds back on the cardholder’s account.

In the store-based model, Refunds are standalone transactions. They aren’t linked with original purchase requests because the customer is in the store, card and receipt in hand. Additionally, the refund has been pre-vetted by an “authorized return” application.

In comparison, the Refund model for web-originated transactions will differ as follows:

• Cardholder information is not included in the request.
• The refund is linked to an original: Since cardholder information isn’t supplied on the return, OLS must find the original in order to process it (search is limited to 90 days of history).
• If an original is not found, result code 2206 is returned (‘Original transaction not found for refund.’)
• The switch will prevent the originator from processing refunds in which the tallied refunded amounts exceed the amount of the original purchase (Result code 2207: ‘Refunded total would exceed amount of original transaction’).
• The switch will prevent the originator from processing refunds in which the original transaction was already reversed (Result code 2203: ‘Original transaction was already reversed’).
• The switch will prevent the originator from processing reversals in which the original transaction already has refunds posted against it. To the originator, the reversal attempt will be accepted, but the switch will not process the request (a non-0000 internal result code will be logged).

Reversal of Refund (a.k.a., ‘Reversal of Return’) – The transaction originator can reverse a refund, but only in the case of system timeout. A refund cannot be voided.

[See Part 2 here.]

[See Part 3 here.]