{"id":161,"date":"2026-05-24T18:30:51","date_gmt":"2026-05-24T17:30:51","guid":{"rendered":"https:\/\/lukaskoren.tech\/?page_id=161"},"modified":"2026-05-27T18:17:01","modified_gmt":"2026-05-27T17:17:01","slug":"merchant-refund-fraud-feature","status":"publish","type":"page","link":"https:\/\/lukaskoren.tech\/?page_id=161","title":{"rendered":"Merchant Refund Fraud Feature"},"content":{"rendered":"\n

MATCHED REFUNDS LITE (MRF)<\/strong> <\/p>\n\n\n\n

TL;DR<\/strong><\/p>\n\n\n\n

Matched Refunds Lite (MRF) at Paymentsense (Dojo) eliminated \u00a3513,000 per month in direct settlement losses – targeting a confirmed annual fraud exposure of \u00a3500,000\u2013\u00a3700,000 across the physical terminal estate. Dojo was the only card payment platform in the UK allowing unmatched refunds: any terminal operator could issue a refund to any card, at any value, with no prior transaction required. A tap-based transaction-matching mechanism, built within the existing Authorisation Gateway, closed that gap in one quarter without ML infrastructure, vendor dependency, or PCI DSS re-scoping.<\/p>\n\n\n\n

CONTEXT<\/strong><\/p>\n\n\n\n

Paymentsense (rebranded Dojo) is a UK payment gateway and acquiring platform serving tens of thousands of SME merchants through physical card terminals. Dojo settles net with its merchant base – refunds issued by merchants are funded directly from Dojo’s settlement pool when merchant liquidity is exhausted. Card-user fraud was outsourced to FeatureSpace, a third-party ML provider. Merchant-initiated refund fraud sat entirely outside that arrangement. Criminal groups posing as merchants, and rogue merchants who had identified the vulnerability, had been exploiting the unmatched refund path for an extended period before detection controls were prioritised. The unmatched refund path in essence is the vulnerability where DOJO terminals would allow refunds that are not linked to a previous transaction. <\/p>\n\n\n\n

PROBLEM<\/strong><\/p>\n\n\n\n

User problem<\/strong><\/p>\n\n\n\n

Any operator with physical access to a Dojo terminal could issue a refund to a random card at a random value – with no requirement that the card had ever transacted with that merchant. There was no verification step, no transaction history check, and no amount constraint. Legitimate merchants shared a platform with rogue operators exploiting the same infrastructure, with no isolation or detection.<\/p>\n\n\n\n

Business problem<\/strong><\/p>\n\n\n\n

Finance, collections, and treasury data triangulated confirmed annual losses at \u00a3500,000\u2013\u00a3700,000. Prior research mapped unmatched refunds onto cards that had never transacted with the originating merchant, on accounts that had entered debit or experienced liquidity shortages – in a limited dataset, this pattern accounted for 90% of all unmatched refund activity. Two fraud patterns drove the majority of losses: established corner-shop merchants issuing refunds that routinely exceeded their own monthly terminal revenue, and newly onboarded merchants receiving terminals and immediately issuing refunds to unknown cards before processing a single legitimate sale. Dojo was, at the time, the only card payment platform permitting unmatched refunds – a structural competitive and reputational exposure beyond the direct P&L loss.<\/p>\n\n\n\n

Technical \/ regulatory \/ operational problem<\/strong><\/p>\n\n\n\n

The Authorisation Gateway was built for routing and approval decisioning, not stateful analysis across transaction history. Card terminal transactions carry no line-item detail – only card identifier, amount, and timestamp – so any matching logic had to operate on amount aggregates rather than itemised records. A further complication was expired card handling: a refund to an expired card is technically valid if the underlying account remains active, because the card is mapped to the account via a PAR (Payment Account Reference). Any solution had to handle the expired card scenario correctly – blocking refunds only where the account was inactive, not where the card had simply expired. This required the solution to work at the tap layer, reading the card’s PAR and transaction history at the terminal, rather than operating purely at gateway level. Finally, any new cardholder data storage would have triggered a PCI DSS scope expansion and QSA re-assessment – a constraint that ruled out a server-side transaction history database.<\/p>\n\n\n\n

APPROACH<\/strong><\/p>\n\n\n\n

The programme opened by converting the fraud loss into a monthly cash drain and modelling the expected value of detection against the cost of false positives.<\/p>\n\n\n\n

Dojo’s net settlement model made the loss arithmetic direct. A fraudulent refund of \u00a3X is a \u00a3X immediate cash loss – not a credit risk, not a chargeback to be recovered, but a real-time drain on settlement capital. The confirmed annual range of \u00a3500,000 \u2013 \u00a3700,000 translated to a monthly burn of \u00a342,000 \u2013 \u00a358,000. The success hypothesis was set at 80% fraud elimination:<\/p>\n\n\n\n

Target monthly recovery = \u00a3500,000 \u2013 \u00a3700,000 \u00d7 80% \u00f7 12 = \u00a333,000 \u2013 \u00a347,000\/month<\/code><\/pre>\n\n\n\n
At \u00a3513,000 recovered per month post-launch, the actual fraud surface was an order of magnitude larger than the triangulated estimate – back-office reconciliation had captured roughly 8 \u201310% of true run-rate exposure.<\/p>\n\n\n\n
The business case was structured around expected value of detection:<\/p>\n\n\n\n
EV(detection) = P(fraud identified) \u00d7 Average refund loss avoided \u2212 [False positive rate \u00d7 LTV cost per declined legitimate refund]<\/code><\/pre>\n\n\n\n
The false positive cost was the controlling variable. Declining a legitimate refund at a physical terminal creates immediate, visible merchant friction. Merchant LTV was modelled as:<\/p>\n\n\n\n
LTV(merchant) = (Average monthly net revenue per merchant \u00d7 Gross margin %) \u00f7 Monthly churn rate<\/code><\/pre>\n\n\n\n
Even a 0.5% false positive rate across the terminal estate translated to meaningful LTV destruction if affected merchants churned. Phase 1 thresholds were set conservatively – maximising precision over recall – with tightening scheduled as false positive data accumulated.<\/p>\n\n\n\n
The solution was designed as two tiers:<\/p>\n\n\n\n
Matched Refunds Lite (MRF)<\/strong> – the Phase 1 delivery. The cardholder taps their card at the merchant terminal. The terminal reads the card’s transaction history and compares cumulative spend at that merchant against the requested refund amount. If the card has no prior transaction with the merchant, the refund is blocked. If the refund exceeds cumulative card spend over the 90-day lookback window, the refund is blocked. The PAR mechanism means this logic applies correctly to expired cards: if the underlying account is still active, the refund proceeds to the expired card and the issuer accepts it. If the account is inactive, the issuer rejects and returns the funds via positive chargeback.<\/p>\n\n\n\n
Matched Refund<\/strong> (Phase 2 scope) – full transaction-level matching, where the original sales transaction is identified and the refund is issued specifically to the originating card. This was deferred: it required deeper transaction record linkage than terminal memory alone could support, and the MRF Lite mechanism was sufficient to address the primary fraud patterns within the Phase 1 timeline.<\/p>\n\n\n\n
The FeatureSpace contract was reviewed and deliberately not extended. FeatureSpace held no merchant transaction history and was trained exclusively on cardholder behaviour. The MRF tap-based approach was faster, auditable, and operable within the existing PCI DSS boundary – extending FeatureSpace scope would have added at least one quarter to the timeline with no marginal accuracy gain for this fraud type. This was documented as a build-vs-buy governance decision.<\/p>\n\n\n\n
The programme ran within a 9-engineer squad over one quarter.<\/p>\n\n\n\n
ARCHITECTURE<\/strong><\/p>\n\n\n\n
The diagram below shows the MRF Lite refund authorisation flow – from terminal tap through transaction-history matching to the settlement or block decision, including the expired card PAR routing.<\/p>\n\n\n\n\n\n
\n\n  
\n    
<\/span>MERCHANT REFUND FRAUD DETECTION \u2014 AUTHORISATION GATEWAY DECISION FLOW<\/div>\n    
PAYMENTSENSE (DOJO) \u00b7 MATCHED REFUNDS LITE (MRF) \u00b7 PHYSICAL TERMINAL ACQUIRING<\/div>\n  <\/div>\n\n  \n    \n      <\/marker>\n      <\/marker>\n      <\/marker>\n      <\/marker>\n    <\/defs>\n\n    \n    \n    \n    \n    \n\n    \n    \n\n    \n    \n    \n    \n\n    \n    \n    \n\n    \n    MERCHANT<\/text>\n    TERMINAL<\/text>\n    AUTH<\/text>\n    GATEWAY<\/text>\n    PAR \/<\/text>\n    ISSUER<\/text>\n\n    \n\n    \n    01<\/text>\n    \n    \n    Merchant initiates<\/text>\n    refund request<\/text>\n    Cardholder taps card<\/text>\n\n    \n    09<\/text>\n    \n    \n    REFUND CONFIRMED<\/text>\n    Issued to cardholder<\/text>\n\n    \n\n    \n    02<\/text>\n    \n    \n    Read card PAR +<\/text>\n    transaction history<\/text>\n    90-day lookback<\/text>\n\n    \n    08<\/text>\n    \n    \n    Relay approval<\/text>\n    to merchant terminal<\/text>\n\n    \n\n    \n    03<\/text>\n    \n    \n    RULE 1<\/text>\n    Card match check<\/text>\n    Prior txn on this card?<\/text>\n\n    \n    04<\/text>\n    \n    \n    RULE 2<\/text>\n    Amount match check<\/text>\n    Refund <= 90-day spend?<\/text>\n\n    \n    05<\/text>\n    \n    \n    EXPIRED CARD?<\/text>\n    PAR lookup<\/text>\n    Account still active?<\/text>\n\n    \n    07<\/text>\n    \n    \n    APPROVED<\/text>\n    Settlement proceeds<\/text>\n\n    \n    \n    \n    BLOCKED<\/text>\n    Unknown card<\/text>\n\n    \n    \n    \n    BLOCKED<\/text>\n    Exceeds 90-day spend<\/text>\n\n    \n\n    \n    06<\/text>\n    \n    \n    PAR lookup<\/text>\n    Is account active?<\/text>\n\n    \n    \n    \n    REJECTED<\/text>\n    +ve chargeback issued<\/text>\n    Funds returned to Dojo<\/text>\n\n    \n\n    \n    \n    \n    \n    \n    tap card at terminal<\/text>\n\n    \n    \n    \n    \n    \n    submit for auth check<\/text>\n\n    \n    \n    \n    NO MATCH<\/text>\n\n    \n    \n    \n    PASS<\/text>\n\n    \n    \n    \n    EXCEEDS<\/text>\n\n    \n    \n    \n    PASS<\/text>\n\n    \n    \n    \n    EXPIRED<\/text>\n\n    \n    \n    \n    NOT EXPIRED<\/text>\n\n    \n    \n    \n    INACTIVE<\/text>\n\n    \n    \n    \n    \n    \n    ACTIVE \u2014 proceed<\/text>\n\n    \n    \n    \n    approval response<\/text>\n\n    \n    \n    \n    \n    \n    refund confirmation<\/text>\n\n  <\/svg>\n\n  
\n    SWIMLANE DIAGRAM \u00b7 MATCHED REFUNDS LITE (MRF) \u00b7 DOJO AUTHORISATION GATEWAY \u00b7 PAYMENTSENSE<\/span>\n    SOLID ORANGE = FORWARD  |  DASHED = RESPONSE  |  RED = BLOCKED  |  GREEN = APPROVED  |  AMBER = PAR \/ EXPIRED CARD PATH<\/span>\n  <\/div>\n\n<\/div>\n\n