Andy Orrock | Payment Systems

Five things that can happen when you remote auth

There's effectively five things that can happen when you attempt to go for an external authorization to a transaction endpoint:

1. You can abort the Query before sending because you hit the threshold.
[Our internal error APPLERR_THRESHOLD. See this 2007 post.]

2. You can find that none of the channels are connected.
[APPLERR_MUXDISC]

3. Your request can time out (partner didn't respond in time).
[APPLERR_QUERYHOSTTO – note that depending upon the interface and your mutual agreement with the partner, you may be obligated to send a conditional reversal of the original request via a SAF queue.  See an earlier write-up on SAF here.]

4. The partner can answer you but deny the transaction request.
[Varies by implementation, but in ISO8583, this value is plucked from Field 39 and gets translated into a non-0000 Internal Result Code.  See piece here on result code translation]

5. The partner can answer you with an approval.

One-shot Watchdog

I’ve spoken in many previous posts about Mux and Channel Management in the jPOS framework (search my blog for ‘channel manager’ to get a flavor of some of these pieces).  In one recent situation, I might have done too good a job getting excited about how it works, most notably the ability of the mux to dynamically remove disconnected or non-reachable destinations from its pool of [nearly] round-robin candidates...and its corresponding ability to dynamically and seamlessly re-add those channels back to the mix once proper communication is re-established. 

OLS is a commercial licensee of jPOS.  Of all the aspects of that framework that delight me, I think Mux And Channel Management rank up there as co-Number 1 with the TransactionManager. 

My “too good a job” came in not explaining to our customer that these dynamic undeployments of channels were part and parcel only of persistently connected channels.  When it comes to their non-persistent – or what we call one-shot – brethren, well, these channels are by their very definition not connected.  So, the dynamic aspects that I adore so much play no role.  How do you know you can’t connect if you’re by nature not connected?  Each new transaction will try anew and discover what the last transaction discovered (historically, one of the many reasons we prefer persistent connections if the option is available).

But it was more than fair for our customer to say, hey, maybe you could devise some type of mechanical equivalent for one-shots.  In response, OLS’ CTO Dave Bergert devised the idea of the One-Shot Watchdog...a component that asynchronously monitors each of the channels in a Mux and – upon determining that one or more of them is non-functioning – moves the offending channel out of the deploy directory to an ‘undeploy’ directory.  QMUX reacts perfectly to that and starts – with immediate effect – to redistribute the traffic to the remaining channels.

One of OLS’ engineers Murtuza Chhil – a true payment industry expert (who we’re thrilled has joined our team!) – implemented this feature in a nice clean manner.  In this video, he’s done a nice five-minute Screencast showing the ‘OSWD’ in action.  That’s his ‘undeploy’ dir on the left, the ‘deploy’ dir on the right.

Balsamiq Mockup of our Rx Response Simulator

I used Balsamiq’s simple but powerful Mockups tool to build a series of screens demonstrating the capabilities of our Rx Response Simulator.  You can see my short five-minute presentation here.

The intent of this exercise was twofold.  First, I used it as a vehicle to gather feedback and gain buy-in from our clients. The screens you see there incorporate the thoughts and ideas of six very thorough reviews by our client.  Mockups are a brilliant way to spur meaningful dialog on new products and services.  They get across intent and meaning a far superior way to a wordy requirements document.  Spending the time up front like this on iterative review cycles is time very well spent.  It’s far easier to incorporate ideas at this stage vs. doing it late in the development cycle.

Second, we use the completed Mockup to get our UX vision into the hands of the development team.  Developers are artists.  So, by no means am I attempting to curtail that artistry by forcing an exact look and structure with Mockups.  Its meant to get the intent of the vision across.  There’s plenty of room left for artistry and, of course, plenty of work required for a good developer to breathe life into that vision.  In fact, each time we go through this exercise I’m blown away by just far our great development team can take these ‘push starts.’  My Mockup is the fuzzy caterpillar.  Their end products are the beautiful butterflies.  Still, it’s a pretty fair caterpillar.

A little context about what the Rx Response Simulator does...

Traditionally, our company had focused on financial payment switches, i.e., transaction processing.  Over the past few years, we’ve adapted those strengths to create similar products and services for the Pharmacy (Rx) adjudication marketplace.  Same basic ideas and goals, but – at a very high level – ISO8583 messages get replaced by NCPDP messages.  You can read a bit more about that project in a previous post.

“Adjudication” is a fancy word for an activity that all consumers know very well: when you walk into a pharmacy and present your health plan benefits card, the transaction(s) conducted to validate you, your plan, your coverage vis-à-vis the prescription you’re looking to get filled...that’s adjudication.  For further insight, check out my 15-Touch Customer Interaction process flow.  Adjudication (and a preliminary step called ‘Local Edit’) are tucked into the Steps 1 and 2 slots there (roll your cursor over “Notes and Narrative” to get more information).

Rx transaction acquirers (e.g., pharmacies, hospitals) use adjudication gateways like Relay Health and Emdeon to connect to the Pharmacy Benefit Management (‘PBM’) players like Argus, Bioscrip Caremark, Express Scripts and Medimpact.  Transactions are formatted as NCPDP 5.1 and D.0 formats.

But suppose someone wants to try out some new NCPDP mandates before the gateways are ready?  Or wants to replay some responses that aren’t being handled properly in a production environment?  Or wants to test some front-end conditions that can only be triggered by specific NCPCP responses?

That’s where our Rx Response Simulator comes in.  It allows our customers to take on any of those needs.  Responses can be hand-crafted field-by-field, or – more powerfully – built directly from full responses captured from a live environment (and pasted into the simulator).

With that as background, the Mockup should make sense. 

Integrating web auths into our switch, Part 2

[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.]

Integrating web auths into our switch, Part 3

[See Part 1 here.]

[See Part 2 here.]

In this third and final piece, I was concerned about originating application writers not understanding that transaction result, card security code result and address verification result  must be evaluated separately.  So, I wrote this additional piece entitled “Transaction Response Processing Notes.”

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

Special attention must be paid to the relationship between the three result code fields: gw_result_code; gw_avs_result_code; and gw_csc_result_code. These are separate results. The originator must examine and evaluate each of them. Neither a mismatched CSC nor a mismatched is necessarily a cause for a DECLINED transaction. In practice, we have seen:

a) APPROVED transactions with matched CSC and matched AVS

b) APPROVED transactions with mismatched CSC and matched AVS

c) APPROVED transactions with matched CSC and mismatched (or partially matched) AVS

d) APPROVED transactions with mismatched CSC and mismatched (or partially matched) AVS

e) DECLINED transactions with matched CSC and matched AVS

f) DECLINED transactions with mismatched CSC and/or mismatched AVS (where the DECLINE is unrelated to the mismatch(es)).

g) DECLINED transactions with mismatched CSC (where the DECLINE is related to the mismatch – a case in which the authorizer has opted to take decision-making out of the originator’s hands by escalating the mismatch to the status of a hard decline).

Other, less frequently seen use cases involve responses indicating that the CSC and/or AVS were not processed – either because the issuer/authorizer does not support the service (a non-transient condition); or, because the service in question is temporarily unavailable (a transient condition).

In cases (b) through (d) – indeed, in any case in which the transaction is APPROVED but the submitted CSC and/or address results in anything less than a match – the originator faces a decision as to how to proceed. This is a decision that cannot be made unilaterally by the implementation team. All actions at this point must be in accordance with processing rules conveyed by the business or application owner.

Let’s take case (b) – APPROVED with mismatched CSC – as an example. Possible actions that can be taken by the transaction originator after evaluating the response include:

Accept the transaction as an approval – In doing so, the organization accepting the transaction forfeits certain chargeback rights.

Request that the customer re-enter their CSC – Before resubmitting the transaction with the new CSC, the originator must submit a void to cancel out the effect of the previous transaction.

The matter of business rules comes into play here – the transaction owner will surely not want the customer to have the freedom to spin through 100 attempts at getting the CSC right. Each business must establish a policy to determine the appropriate number of re-attempts. Authorizers like American Express enforce a policy from the other end by escalating mismatched CSCs to a hard DECLINE on a third consecutive, failed attempt with the same card.

Deny the transaction – The organization may decide to let the mismatched CSC trump the APPROVED decision. A typical policy may be to allow a limited number of shots at a re-entered CSC before deciding to overtly deny the transaction. Should this decision be taken, the originator must submit a void to cancel out the effect of the previous transaction.

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

Illustration of the 15-touch customer interaction

I just concluded a really fun, rewarding Elance engagement in which I commissioned a project to illustrate and animate the 15-touch point-of-sale interaction that I described in this piece.  You can see the results here.  We'll put the results up on our home page later this week.

The results are meant to be self-explanatory, so I won't belabor the point here.

If you liked how this turned out, I recommend you check out my service provider, Light Within Productions (a.k.a., Ace Light).  I had a really great experience on this project - my best Elance experience to date.

Developers and Project Managers

Our firm, On-Line Strategies, is going through a growth spurt, the result of hard work, attention to detail, successful projects and happy customers.  We’re on the lookout for new people to join our team. 

We have two immediate needs:

First:  Developers, Developers, Developers, Developers!  These positions report to Dave Bergert, OLS’ Technology and Development Director.  [See Dave’s blog here.] Dave's in the process of putting together some ads that will run on key forums.  But if you’re a regular reader of this blog, you know what we do.  Contact Dave directly to present your qualifications.

We're of the opinion that good technical talent knows no boundaries.  So, even though our HQ is in Dallas, TX, USA, don't be afraid to pitch your qualifications no matter where you are.

Second:  We’re scouting for Project Managers.  Our PMs are payment systems specialists who: interact with customers; gather and document business requirements; identify and create add-on business opportunities; present and explain development needs to Dave and his team; review unit tests; create test plans for customers; craft go-live plans; create internal documentation and release notes; manage customer expectations; interact with other PMs to find synergies and identify like solutions; expand and refine our on-boarding processes; participate in technical sales calls; assist in production support efforts; write blogs to expand our online presence; and…you get the idea.

Put another way, our PMs do everything in the customer lifecycle except sales (we have a team for that) and design, development, technology choices and hard-core production support (Dave’s team - see above).

Send me an e-mail expressing your interest and qualifications.  Unlike developers, our PMs need to be US-based in order to travel to our clients.

We look forward to hearing from you!

March 16, 2011: Day of Dual Milestones

We marked March 16th as The Day of Dual Milestones at our flagship acquirer-side OLS.Switch implementation.

First, on the Rx adjudication side, our client turned on the spigot on NCPDP format D.0 processing.  This was a seminal event.  Thinking back to the impetus of the effort to creation a switch capable of handling adjudication transactions, it was the D.0 mandate that spurred the whole thing.  The US Federal government (providers of Medicare and Medicaid services) has mandated a January 1, 2012 deadline for switchover to the D.0 standard.  Like most players in the industry, our client was processing NCPDP 5.1.  They made a strategic decision not to develop D.0 functionality on their legacy platform...kind of a moot point because that platform didn't have the juice to do it anyway.  Those facilities were already taxed to the max by 5.1.  The D.0 standard represents about a 2.5x burden in terms of maximum message length, as well as increased formatting complexity. 

Ergo, the switch to OLS.Switch.  While we've fully converted all traffic to our platform on the 5.1 standard, seeing the first upshots of D.0 traffic reminds us of why we were drafted for the effort in the first place.  The best part of the whole milestone: how it happened almost without notice...just an offhand comment in a status meeting that, oh yeah, D.0 got turned on that morning and "all looks good."  That's the best kind of conversion: zero drama.

Second, on the Loyalty engine side, that same client went live with their Electronic Coupons ('eCoupons') initiative.  We've been processing serialized coupons for some time now (the kind you get at the bottom of your receipt as an enticement to make a return visit), but eCoupons are quite different in character.  In an internal document, I summarized the difference between eCoupons and serialized coupons for my colleagues:

eCoupons differ in following way:

• Serialized coupons are meant to be redeemed in return visits by the customer.  By contrast, eCoupons are geared to be presented to the customer for real-time use in the current sale.
  
• OLS creates (‘issues’) serialized coupons indirectly through message management. By contrast, [OLS' client] 'issues' eCoupons directly by loading them straight into the new loyaltyecoupon table.
  
• Serialized coupons are redeemed individually in a special Loyalty Lookup transaction.  If voided, that is noted subsequently in a Market Basket Analysis ('MBA') transaction.  By contrast, eCoupons are redeemed en masse at the point-of-sale.  If redeemed, that fact is noted subsequently in an MBA (a single MBA would contain a record of all redeemed eCoupons).

We've supported up to 150 million active serialized coupons on file at any given time for this client's 35 million-strong cardholder base.  We expect the number of active eCoupon offers we support could be several times that number.

More than just a payment system (Part 2)

Related post:

Part 1

---------

2011.04.02 Update:

I did a Flash presentation to accompany and illustrate this piece.  See it here.

---------

In sports like basketball and football - both the US and ROW (rest of the world) versions - your game is bound to improve as you increase your number of 'touches.'  It's the same way with transaction processing: the more you control, the number of transactions you see, the variety of the business interactions in which you're called upon to add value...all these things add up to making you better at what you do.

So, it's a notable to take a look at our growth over the past couple of years.  Our peak days at our largest customers have gone from one million to eight million.  What's driving the growth?  We're increasing our touches.  Circa 2006, when a customer came into one of our clients' locations, our acquirer-side switch executed the payment card transaction.  One and done.

Now, by contrast, I can detail a very plausible 15-touch scenario. 

To set this up: envision the all-too-familiar task of going to a retail location that has an in-store pharmacy.  You've gone in to get a prescription filled and to make a few incidental purchases.  Here's the tale of the tape...

Touch #1:  You present your benefits card and prescription information to the pharmacist.  They perform a 'local edit' to pre-validate certain aspects of the transaction before submitting it to an external adjudicator.  This touch hits our Rx Edit Engine for internal processing.

Touch #2:  Next up, the adjudication step.  This touch hits our Rx Adjudication Engine and involves us switching out transactions to Relay Health and Emdeon, the country's leading connectors of payers, providers and patients.

Touch #3:  The customer belongs to our client's excellent loyalty program!  But, alas, they've forgotten their card.  ¡Qué lástima!  Never fear, phone look-up is here!  In this touch, the customer provides a phone number and we find and return the hits from our Loyalty Engine (internal processing). 

Let's assume that we found three cards with that phone number (this happens A LOT -- various members of the household sign up for the program). 

Touch #4:  At the point of sale, the customer is presented with the three account records we located.  He or she selects the account that is theirs.  At that point, the point-of-sale fires a Loyalty Look-up transaction at us.  In this touch, we do an internal look-up in our Loyalty Engine to find the card, determine the customer's 'discount tier' and see what type of 'targeted messages' are currently associated with the account. 

If targeted messages are available and contain embedded serializable coupons, we serialize the coupon(s), record them on our coupon database, add them to our reply.  [NOTE: The goal of a serialized coupon is to create a degree of lock-in for a return visit.]

If electronic coupons are available, we add them to the reply as well.  [Unlike serialized coupons, electronic coupons can be used immediately.]

Touch #5:  The customer has two serialized coupons from a previous visit that they're looking to use in this sale.  It's up to us to validate them.  In this touch, our Loyalty Engine checks our internal database to determine if (a) the coupon is on file; (b) the offer is still valid; and (c) the coupon was not already used.

Touch #6:  We validate the second serialized coupon.

Touch #7:  One of the products the customer is seeking to purchase contains Pseudoephedrine ('PSE').  It's MethCheck time.  In this touch, the non-PCI branch of our Financial Engine formats an external request to PSE national database provider Appriss, Inc. 

Touch #8:  Market basket analysis!  We get a transaction consisting of (a) all the goods (item by item) a customer is purchasing; and (b) the electronic coupon offers that the customer chose to activate at the point-of-sale.  This touch is a thick, complex internal/external undertaking by our Loyalty Engine - we tick off the electronic coupons locally and assemble a series of external transactions consisting of the market basket items. We send these requests to an external 'offer engine' (like this one).

In response, the offer engine sends us back a series of 'triggered' messages ('triggered' in this context meaning that the presence of a specific item in the market basket has triggered an offer for another product).  We analyze those messages and - if they contain serializable coupons - perform the serialization routine described in Touch #4.

Touch #9:  Payment time!  The customer has some SIGIS Eligible Products in their market basket, so they decide to use their Health Savings Account ('HSA') card to make this purchase.  The point-of-sale's SIGIS-approved IIAS catalog figures out what products are eligible and sends us a transaction that denotes the total amount, the sub-total of over-the-counter medical items and the sub-total of prescription Rx items. 

In this touch, the PCI branch of our Financial Engine does some pretty heady transformation of the message and sends an authorization request to the card issuer, either via a payment gateway like FDR North or Fifth Third (to cite two examples) or direct to an association (i.e., MasterCard, Visa, Discover, etc.).

Because of the byplay of item qualification and varying HSA program coverage rules, the instances of partial approval in these situations are frequent.  So, let's put that in play here.  We format a partial approval back to the originator, making note of what amount got authorized.

Touch #10:  Confronted with news of the partial authorization, the customer is asked to provide a second form of payment.  What to do next?  They have options: void the sale and provide a new form of payment; void the sale and walk; provide a second form of payment to cover the difference; modify the market basket (i.e., take enough items out of the market basket so that the approved amount covers the purchase).  

Let's go for a combination of the last two: the customer also has in-hand a store-branded stored value card ('SVC') they want to use...except they don't know how much money they have on the card.  So, they ask the associate to do a balance inquiry.  In this touch, PCI branch of our Financial Engine goes external to format and send a balance inquiry transaction to the SVC's program provider.

Touch #11:  Balance in hand, the customer makes a decision: they remove two items from their market basket and use the SVC to cover the remainder of the purchase.  In this touch, we go external to the same provider (see Touch #10) with a purchase authorization request.

Touch #12:  Now, we have to notify the offer engine to void one or more of the products from their historical database.  And, if a serialized coupon had been previously validated in conjunction with the purchase of one of those products (see Touch #5 and #6), we need to roll back that usage.  In this touch, our Loyalty Engine receives a follow-up market basket analysis transaction in which we decrement the usage counter on the serialized coupon (internal) and format a void notification to send to the offer engine (external).

Touch #13:  Now, let's suppose that among the items purchased was a gift card from one of those near ubiquitous gift card malls that populate the end-caps of retailer aisles everywhere.  That card needs to be activated!  That's us again.  In this touch, the PCI Financial Engine formats and sends a card activation transaction to the appropriate stored value card network (in a typical implementation we manage a series of these interfaces).

Touch #14:  Lastly, the customer came into the store carrying a good they bought last time they were in.  They wish to return it.  Returns (a.k.a., refunds) are a source of major retail fraud.  These are unalloyed - systematically - from the related purchase from a payment systems perspective (as opposed to reversals, in which we need to seek for and find an original purchase in order to execute the transaction).  To minimize fraud, many retailers put an "authorized return" service into place.

In this touch, our Non-PCI Financial Engine routes the incoming 'authorized return' request to an internal service sitting elsewhere in our client's data center.

Touch #15:  If the authorized return request in the previous touch is approved, the ability to do a payment card refund is unlocked at the point-of-sale (I'm assuming the original purchase was performed on a card).  In this touch, our PCI Financial Engine process the refund.  Credit card refunds (and those of their offline debit card brethren) are handled offline.  We write the transaction to our logs and extract it later that evening in the file we prepare to send to our gateway sponsor.

Final Word:  Not only could this happen, it does happen.  Repeatedly and consistently.