Fraud verdicts for Gilbarco Passport siteswithout touching the POS or the pumps.RankShield integrates beside a Gilbarco Passport installation, not inside it: it reads the transaction journal the back office already exports and the authorization detail your processor already reports, scores both in real time, and seals every verdict to the RankShield Network — while Passport, the forecourt, and the payment path keep running exactly as they do today.
What a Passport site already produces
Passport is the point of sale and the brain of the forecourt: it drives the dispenser card readers, runs the registers inside, and hands every card authorization to the payment network. Along the way it produces the two data streams fraud detection needs. First, a transaction-level journal — sales, refunds, voids, no-sales, cashier and register identifiers — exposed through the back-office interface in the industry-standard NAXML format that back-office systems consume. Second, the authorization records themselves, which your processor sees for every pump and register transaction, including the terminal that originated it and how the card was read.
Why we integrate beside it, not inside it
A fuel POS is certified, hardened, and busy — the last place to bolt on new software. RankShield therefore takes the read-only position: journal feeds from the back office, authorization detail from the processor side. That is enough to run velocity scoring per dispenser terminal, fallback-rate divergence per pump, and refund-chain analysis per register — with zero changes to price book, forecourt configuration, or the payment path.
Three tap points, zero store changes
Each feed already exists at the site. The integration directs it to one additional recipient you control.
Back-office journal feed
The journal export Passport already provides to back-office systems carries register-level events — refunds, voids, no-receipt returns, cashier and shift identifiers. This powers refund-chain and register-level rules.
Processor authorization detail
Authorization records from your acquirer carry terminal ID, amount, timestamp, and card-entry mode. This is where card-testing velocity and chip-fallback divergence per pump become visible.
Fleet back office, if present
If stores roll up to a fleet back-office platform, one integration there covers every site’s journal at once — usually the fastest Phase-1 path for a chain.
Reading a Passport site through the export interface it already runs
Passport is not a black box: it ships a named, configurable file-export gateway, and that gateway is the door RankShield reads through.
On this stack specifically: Card-entry-mode signals (chip versus fallback swipe) come from the processor-side authorization data, not the POS journal — so the skimmer-signature rule needs the processor feed connected, not just the back office.
The XML Gateway is the door, not a new one
Passport carries an XML Gateway that publishes site data on a configurable file-polling cycle, with the interface format set to a NACS XML convention and an output directory the operator controls. Chains already point that gateway at accounting and fuel-reconciliation systems. RankShield becomes one more authorized destination for the same export, reading the sales, refund, void, and shift records Passport writes there. Nothing on the register or the back-office server is re-engineered: the export exists, the polling cycle exists, and the operator simply designates an additional recipient. That is what keeps the first phase a configuration task on data Passport already publishes, rather than any change to how the site rings a sale or authorizes at the pump.
Where the card is actually read: the forecourt controller
On a Passport forecourt the dispenser card readers do not talk to the register directly. They sit behind a forecourt controller, such as the DOMS PSS 5000, that drives the pumps and passes authorizations upward. That physical layer is exactly where a shimmer lives, and where a chip read is forced to fail over to magstripe. RankShield does not touch that controller or the readers it manages. It reads the authorization detail those pumps generate from the processor side, so a fallback-rate break on one dispenser position becomes visible as data without any presence on the forecourt hardware. The forecourt stays a certified, sealed system; the signal it leaks is read from beside it.
What the gateway export cannot tell you, and what completes it
Two things the XML Gateway export cannot carry on its own: whether a card was dipped or swiped, and which authorizations the processor declined. Passport writes completed sales and register events there, not the response codes behind them. So the skimmer and card-testing rules on a Passport site are only as good as the processor feed paired to them: the gateway supplies the register and shift half, the authorization detail supplies the pump-and-card half, and RankShield joins the two per dispenser position. A deployment that connects only the XML Gateway gets refund-chain and register coverage; the physical-skimmer signature waits on the authorization side being connected too. The page states which half each rule depends on.
The fraud these feeds make visible
Each rule family maps to a documented, measured loss pattern in fuel and convenience retail.
At a Passport site the highest-value fraud hides at the unattended dispenser overnight: a stolen-card batch validated in small authorizations at one pump, or a shimmer forcing that pump to fall back to magstripe while its neighbors read chips normally. Neither shows in the XML Gateway export, which records completed sales, not declines or card-entry mode. The processor authorization feed is what makes both visible, scored against that specific dispenser position’s own baseline rather than a storewide average.
Is your site data ready for this?
Each question maps to a feed or control this integration depends on. The tally runs in your browser — nothing is transmitted.
- 01Does your back office already aggregate a NAXML journal across your sites?
- 02Can your processor deliver authorization detail including declines and card-entry mode?
- 03Today, can you see declined authorizations per pump — not just completed sales?
- 04Would a fallback-rate spike on one pump trigger anything automatically?
- 05Are refunds and voids scored per register and per employee each shift?
Answer all 5 to see where you stand · 0/5
The rollout that cannot break your stores
The default state at every phase is no-change: nothing is blocked until observe mode has proven accuracy on your own store traffic.
Connect the data, touch nothing
RankShield consumes feeds this stack already produces — transaction journals, authorization detail, settlement files. Nothing is installed on registers, pumps, or terminals, and no payment path is modified.
Observe mode builds the baseline
The rail scores live traffic and shows what it would have flagged — per terminal, per register, per store — so accuracy is proven on your own data before any transaction is touched. If RankShield is ever unavailable, the default is fail-safe: payments flow.
Enforce where the numbers earn it
Holds and blocks are enabled surface by surface, and every verdict is sealed to the RankShield Network with a receipt you can verify independently — so a declined payment always has a checkable answer to “why?”
What the rail watches on this stack
- Authorization velocity per dispenser terminal against that pump’s own baseline
- Chip-read fallback rate per pump versus its neighbors — the skimmer signature
- Refund and void chains per register, per shift, per destination card
- A sealed, independently verifiable receipt for every verdict
An integration path, not a partnership claim
Gilbarco Passport is a product of Gilbarco Veeder-Root. RankShield Financial is an independent platform and is not affiliated with, certified by, or endorsed by Gilbarco Veeder-Root. This page describes RankShield’s supported integration architecture for merchants who run Gilbarco Passport: it consumes data feeds the merchant already owns and directs — transaction journals and processor reporting — and never modifies the named system or its payment path. We hold every page on this site to the same standard as our verdicts: claims you can check.
References
Standards are cited to the bodies that maintain them; fraud statistics to government and association primaries. Measurements from industry vendors are labeled as such.
- Conexxus — NAXML data standards for convenience and fuel retail
- ISO — ISO 8583 financial-transaction card messaging standard
- EMVCo — EMV chip specifications (governing body)
- PCI Security Standards Council — PCI DSS
- U.S. Secret Service — Nationwide Crackdown on Card Skimming and Fraud
- Imperva / Thales — 2025 Bad Bot Report (industry measurement)
- Visa — Anti-Enumeration and Account Testing Best Practices
- ACFE — Occupational Fraud 2024: A Report to the Nations
Integrating beside Gilbarco Passport, answered
Every question buyers ask before they trust a payment-security platform, answered directly.
JAMIE KLONCZ · RANKSHIELD FINANCIAL ONLINEPick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.
Other integration paths
Start with your own data, not our promises.
Phase 1 is a findings report on sixty to ninety days of your existing journal and authorization history: what the rules would have caught, store by store, before anything touches production.