2026-10-09 Author : ZCS
Least-cost routing matters because the same debit card payment can reach the same bank account through different payment networks at different merchant costs. An EFTPOS terminal fundamentals guide explains the device’s wider role at checkout; LCR concerns the narrower decision about which network carries an eligible debit transaction.
Least-cost routing (LCR), also called merchant choice routing, lets a merchant send an eligible dual-network debit card transaction through the lower-cost available network. In Australia, the choice is commonly between eftpos and Visa Debit or Debit Mastercard. LCR does not apply to credit-card transactions.
The customer normally sees no change at checkout. The purchase still draws funds from the same deposit account, and the terminal still returns an approval or decline. The routing choice changes the network used between the checkout and the issuing bank, which can change the fee paid by the merchant.
A dual-network debit card can process a domestic payment through two card networks. Most Australian examples carry eftpos alongside either Visa Debit or Debit Mastercard. Both routes generally access the same customer deposit account, but the merchant’s acceptance cost can differ between them.
A contactless tap would otherwise follow the card’s default network. That default has commonly been the international debit network printed on the card. The merchant may therefore pay the international-network rate even when eftpos would cost less for that transaction.
LCR gives the merchant or payment provider a routing choice. The RBA least-cost routing guidance defines LCR as the ability to send a dual-network debit transaction through the network that costs the merchant less to accept. The function is also called merchant choice routing.
The selected network changes the processing path rather than the source of funds. A transaction routed through eftpos and the same transaction routed through Visa Debit or Debit Mastercard still debit the customer’s linked deposit account.
Customer protections remain attached to the transaction framework. The RBA states that the three debit networks provide similar protection against fraud and disputed in-person transactions. Specific chargeback processes and service features can still differ, so routing policy should consider more than the headline fee.
A customer can override merchant routing for an in-person payment. Inserting the physical card and selecting a network allows the cardholder to choose a route instead of using the contactless default. Tapping usually leaves the routing decision to the card configuration and any LCR rules applied by the merchant’s provider.
Credit-card transactions do not qualify for LCR. A credit card does not present the same eftpos-versus-international-debit choice, even when the issuing bank also offers debit cards.
Single-network cards also cannot be rerouted. The terminal needs two available debit applications before a routing rule has anything to compare. An eftpos-only card or an international-network-only debit card follows its available network.
Mobile-wallet and online support must be checked separately. Tokenisation and gateway design can determine whether both debit networks are available in a digital form factor. A provider that supports LCR for a physical tap may not offer the same choice for Apple Pay, Google Pay, or an online checkout.
The routing decision begins when the terminal reads the card or token. The payment application identifies whether the credential represents an eligible dual-network debit card and which network applications are available for the transaction.
The terminal then applies rules supplied by the payment provider. Those rules can consider the merchant account, transaction amount, supported networks, provider pricing, and other technical conditions. The terminal does not independently search public network prices during every tap unless the provider has implemented a dynamic routing model.
The selected route becomes part of the normal authorization request. The wider EFTPOS transaction process still includes card reading, encryption, transmission to the acquirer, issuer authorization, approval or decline, and later settlement. LCR changes the network-selection stage inside that process.
Binary routing sends eligible transactions to one preferred network. A provider may route qualifying debit taps to eftpos because that network is cheaper on average for the merchant’s pricing arrangement. Binary routing is simple, but it does not compare the cost of every transaction.
Threshold routing changes the route at a defined transaction value. Percentage-based and fixed per-transaction fees can cross at a particular purchase amount. A provider can route transactions below the threshold through one network and larger transactions through another.
Dynamic routing evaluates each transaction against current merchant pricing. Dynamic LCR offers the closest match to the phrase “least cost,” but it requires detailed fee data and more sophisticated processing. The RBA reported in March 2026 that very few payment service providers offered true transaction-level dynamic routing.
| LCR method | Routing logic | Main limitation |
|---|---|---|
| Binary | Sends eligible transactions to one preferred debit network | Does not compare individual transaction costs |
| Threshold | Changes network above or below a preset value | Accuracy depends on a correctly maintained threshold |
| Dynamic | Compares eligible networks for each transaction | Requires detailed pricing data and provider integration |
An EFTPOS terminal cannot create a network route that its acquirer does not support. The acquirer or payment facilitator connects the merchant to eftpos, Visa, and Mastercard and determines which certified payment applications and routing services are available.
Merchant configuration determines whether the available function is used. A provider can offer LCR but leave it disabled until the merchant opts in, or enable it by default under the merchant agreement. A terminal replacement may be necessary when older hardware or software cannot accept the required payment application update.
Transaction reporting should record the route actually used. Merchant statements or payment dashboards need to identify eftpos, Visa Debit, or Debit Mastercard so the business can compare routing outcomes with its fee schedule.
An NFC reader only provides the contactless communication channel. LCR also requires certified payment applications that can recognise both debit networks, apply the provider’s routing rules, and pass the selected route into the authorization message.
A terminal advertised as “eftpos compatible” may still lack merchant-choice routing. Basic compatibility can mean the device accepts eftpos when a customer inserts a card and chooses SAV or CHQ. Automatic routing of a contactless tap requires additional software and acquirer support.
Terminal age can become an implementation barrier. The RBA notes that enabling LCR may require a payment software upgrade and, in some cases, replacement of the terminal. Buyers should confirm upgradeability before treating LCR as a future software option.
An LCR-capable EFTPOS setup requires more than NFC hardware. The terminal software, card-network applications, acquirer host, merchant pricing rules, and remote configuration must all support routing. A compatible terminal cannot activate LCR by itself when the payment provider or merchant plan does not make the function available.
Payment certification protects interoperability but does not define the merchant’s routing price. EMV contactless approval can establish that the terminal communicates correctly with supported card applications. The merchant agreement still determines which routes are enabled and what each route costs.
Routing logic must preserve every approved transaction control. Network selection cannot bypass cardholder verification, cryptographic checks, or the security rules attached to the payment application.
Remote terminal management makes routing changes practical across a fleet. A payment provider may need to update network priorities, thresholds, application parameters, or surcharge settings across thousands of terminals. Manual reconfiguration at every checkout would make ongoing LCR maintenance slow and expensive.
A merchant cannot validate LCR without route-level reporting. A useful statement should identify the debit network, transaction count, transaction value, fees, and effective cost for the reporting period.
A low-cost route at the wholesale level may not appear on a fixed-price statement. The provider can reduce its own network cost while continuing to charge the merchant the same flat rate. That arrangement can still increase competition between networks, but it does not create an immediately visible saving for the individual merchant.
LCR is now available to virtually all card-present merchants covered by RBA reporting. The September 2026 LCR update reports that 83% of merchants had LCR enabled for in-person transactions at the end of June 2026. Another 9% had no active enablement choice recorded, while merchant or acquirer decisions accounted for the remainder.
Provider-level enablement still varies. The RBA table reports rates ranging from 31% for one major provider to 100% for another. Availability therefore does not establish that a specific merchant account has LCR switched on.
RBA data published in September 2026 shows LCR was available for virtually all card-present merchants and enabled for 83 percent. Online availability reached 98 percent, but enablement rates varied widely by provider. High LCR availability therefore does not guarantee that every merchant receives the lowest overall acceptance cost.
Online LCR was available to 98% of merchants in the June 2026 RBA data. Actual enablement varied sharply across payment providers, and some acquirers still depended on further gateway or third-party integration.
A gateway can block a route even when the acquirer supports it. Online payments pass through software platforms that tokenise credentials, manage fraud checks, and submit authorization messages. Each intermediary must preserve both network options for LCR to work.
Mobile wallets remain a separate verification point. A tokenised dual-network card must have both networks provisioned in the wallet and supported through the provider’s processing path. Merchants should not infer mobile-wallet LCR from physical-card support.
Australian card-surcharge rules changed on 1 October 2026. The eftpos, Visa, and Mastercard networks introduced no-surcharge rules covering debit, credit, and prepaid card transactions. Many payment providers also removed terminal surcharging functions around the changeover.
The new rules make payment cost control more important inside the merchant’s pricing model. A business can adjust its advertised prices, but it can no longer add a separate card surcharge at checkout for the affected networks. The detailed 2026 EFTPOS surcharge rules explain the scope and implementation date.
LCR can reduce one component of the cost now absorbed by the business. Network routing does not remove terminal rental, gateway fees, acquiring margins, software charges, or fraud-management costs. It can only affect eligible debit transactions where two routes are available.
The surcharge change governs what a merchant may charge the customer. LCR governs how an eligible debit transaction moves through the payment system. A business needs to manage both issues, but one does not automatically configure the other.
Terminal configuration must reflect the post-October rules. A device may need one update to remove card surcharging and another payment-application configuration to enable LCR. Payment providers often manage both remotely, which can make the changes appear to be one feature even though they perform different functions.
The RBA’s current policy applies across designated card networks. The RBA surcharge removal guidance confirms that eftpos, Mastercard, and Visa introduced no-surcharge rules from 1 October 2026. American Express, UnionPay, and PayPal also announced aligned changes.
The terminal must support the required contactless and chip applications. Buyers should confirm eftpos, Visa Debit, and Debit Mastercard acceptance for the intended acquirer rather than relying on a generic NFC specification.
The payment application must receive secure updates. Routing tables, application identifiers, card-network parameters, and transaction thresholds can change during the terminal’s service life. Signed software distribution and controlled remote configuration reduce the risk of unauthorised changes.
Routing changes also need clear operational control. Providers should document who can change priorities, how updates are approved, and how faulty configurations are rolled back.
Contactless security remains independent of the route selected. LCR does not replace EMV processing, encryption, tokenisation, or PCI controls. A buyer evaluating routing should also verify the relevant contactless payment security standards for the complete acceptance environment.
The acquirer must make both networks available for the merchant account. A terminal cannot send an eftpos transaction to a host that accepts only the international network for that card form factor.
The pricing plan must provide a usable cost comparison. Dynamic routing requires transaction-level fee information. Binary and threshold methods can operate with simpler assumptions, but those assumptions need revision when network or merchant pricing changes.
The provider must decide how savings reach the merchant. Interchange and scheme fees are only parts of the merchant service fee. A lower network cost can be absorbed inside a flat price unless market competition or the contract passes it through.
A useful LCR report connects route selection with cost. Network names alone do not show whether the chosen route was cheaper. The merchant needs transaction value, charged fee, effective rate, and enough detail to separate debit from credit.
Performance reporting should include unsuccessful routes. Approval rates, fallback behaviour, reversals, and technical declines can affect the operational value of a network. The lowest nominal fee is not the lowest practical cost when a routing configuration increases failed payments or support work.
| Requirement | What to confirm before deployment |
|---|---|
| Dual-network recognition | Physical cards and supported tokens expose both debit networks |
| Routing method | Binary, threshold, or dynamic rules are documented |
| Acquirer support | The merchant account can submit transactions to both networks |
| Remote configuration | Routing parameters can be updated securely across the fleet |
| Mobile-wallet coverage | Apple Pay and Google Pay support is confirmed separately |
| Online coverage | Gateway and token service preserve both network options |
| Route reporting | Statements identify the network used for each transaction class |
| Security and certification | EMV, PCI, encryption, and software-update controls remain valid |
The first question is whether LCR is enabled on the merchant account, not merely available. The payment provider should identify which transaction types qualify and whether activation requires an opt-in, software update, contract change, or terminal replacement.
The second question is which routing method the provider uses. A merchant should know whether all eligible taps go to one network, whether a value threshold applies, or whether the provider compares transaction-level cost.
The third question is whether the price paid by the merchant changes. A fixed-rate plan may show no direct reduction even when the provider routes transactions through a lower-cost network.
Merchant statements should reveal the network used for eligible debit transactions. A business can compare route mix, transaction value, and effective fees before and after enablement. The comparison should cover a representative trading period rather than a handful of test payments.
Physical cards, mobile wallets, and online transactions should be tested separately. Support for one form factor does not establish support for the others. A card that routes through eftpos when tapped may use an international network when tokenised in a wallet.
Terminal procurement should include written confirmation of provider compatibility. The broader EFTPOS terminal buying checklist covers connectivity, certification, form factor, and software integration alongside routing support.
The correct comparison is total payment cost rather than the cheapest individual network fee. Terminal rental, monthly software charges, gateway fees, minimum fees, settlement services, and acquiring margins can outweigh a small routing difference.
Transaction mix changes the result. A café with many low-value debit taps can experience a different outcome from a furniture retailer with fewer high-value transactions. The same threshold or fixed routing rule will not optimise both merchants equally.
A flat transaction rate can conceal network-level savings. The provider may pay less after routing more traffic through eftpos while charging the merchant the same published rate. LCR still creates competitive pressure, but the statement may not change.
Eftpos is not automatically the cheapest route for every transaction. Percentage fees, fixed fees, transaction size, volume discounts, and individual commercial agreements can make an international debit network cheaper in some cases.
Merchants may value capabilities beyond the transaction fee. Approval performance, token support, dispute handling, refunds, fraud tools, loyalty integrations, and reporting can differ between providers or network paths.
Older terminals can make LCR uneconomic for a small merchant. A hardware replacement, software certification project, contract migration, or gateway integration may cost more than the expected fee reduction. The decision should compare implementation cost with realistic transaction volume and contract duration.
A terminal buyer should verify routing capability before signing a hardware or acquiring contract. The following questions separate genuine LCR readiness from a general claim of eftpos or contactless support:
LCR readiness is a property of the complete acceptance service. The terminal is necessary because it reads the credential and applies the payment application, but the merchant cannot obtain least-cost routing without compatible acquiring, pricing, provisioning, and reporting.
Least-cost routing allows a merchant or payment provider to send an eligible dual-network debit card transaction through the lower-cost available network, commonly choosing between eftpos and Visa Debit or Debit Mastercard.
No. Binary routing may prefer eftpos, but threshold and dynamic routing can select an international debit network when that route costs less under the merchant’s pricing arrangement.
No. LCR applies to eligible dual-network debit transactions. Credit cards and single-network debit cards do not provide the same choice between eftpos and an international debit network.
Some terminals can receive a payment-application or configuration update. Older hardware may require replacement when it cannot support the necessary applications, security requirements, or remote configuration.
Support varies. Both debit networks must be provisioned in the wallet token, and the wallet, issuer, terminal, acquirer, and payment provider must preserve the routing choice. Physical-card LCR does not guarantee mobile-wallet LCR.
The payment provider’s transaction dashboard or merchant statement should identify the processing network. Merchants should request route-level reporting when that information is missing.
No. LCR can lower the network cost of eligible debit transactions, but the merchant’s total result depends on pricing structure, transaction mix, provider margins, terminal costs, and whether savings are passed through.
Home 
Is Palm Vein Data Safe? Template Storage, Encryption and Privacy Law 
