One back-office connection,every store’s fraud baseline at once.For a chain whose stores roll up to PDI back-office software, RankShield’s fastest integration path runs through the data PDI already aggregates: every site’s transaction journal, register events, and shift detail in one place. One connection there, plus authorization detail from your processor, gives the fraud rail fleet-wide coverage without touching a single store system.
Why the back office is the best first tap
Fuel and convenience chains already solved the hard data problem for us: the back-office platform polls every store’s POS journal — sales, refunds, voids, cashier and shift identifiers — into one aggregated system for accounting, fuel reconciliation, and loss prevention. For a chain on PDI, that means the register-level half of fraud detection needs exactly one integration, not one per store. Phase 1 — the historical baseline run — is often possible from data the back office already holds, before any live feed is stood up.
What the back office cannot see, and what completes it
Journal data shows what the register recorded; it does not show how the card was read or what the processor declined. Card-entry mode, authorization-versus-decline detail, and terminal-level auth velocity live in your acquirer’s reporting. The complete picture is the pair: PDI-aggregated journals for register and shift behavior, processor authorization detail for pump-level card behavior. RankShield correlates the two per store, per terminal, per shift — and seals every resulting verdict to the RankShield Network.
Three tap points, zero store changes
Each feed already exists at the site. The integration directs it to one additional recipient you control.
Aggregated journal data
The store journals PDI already collects — refunds, voids, no-receipt returns, cashier IDs, shifts — become fraud-rule inputs for every site at once.
Historical baseline
Sixty to ninety days of history the back office already holds is usually enough to run the full rule set offline and show what would have been caught, store by store.
Processor authorization detail
Card-entry mode and per-terminal auth data come from the acquirer side and pair with the journal to power pump-level velocity and fallback rules.
PDI sits above the stores, so it is read as the aggregation point
PDI is not a store POS: it is the back-office and ERP layer the stores roll up into, which changes what reading it means.
On this stack specifically: Back-office journal cadence varies by configuration — from near-real-time to daily polling. Observe-mode latency inherits that cadence on the register side; the processor authorization feed is what carries the fast-moving pump-level signals.
The roll-up, not a register: one tap covers the fleet
PDI Enterprise is the odd system in a fuel stack: not a register, but the back-office and ERP platform a chain’s stores report up into for accounting, fuel reconciliation, pricing, and loss prevention. It polls each site’s POS journal into one aggregated store of sales, refunds, voids, and shift detail, whatever POS each site runs. That makes PDI the single most efficient tap in the whole stack, because the register-level half of fraud detection needs one integration at the roll-up rather than one per store. RankShield reads PDI as the aggregation point it already is: the fleet’s journal history in one place, directed to an additional recipient by the operator who owns it.
The wholesale and dealer-billing layer a store POS never sees
Because PDI reaches beyond the store into wholesale and distribution, it holds records a store POS never sees: fuel orders tracked from quote to collection, EFT customer billing, dealer invoicing, and electronic supplier-statement reconciliation. A fraud rail that reads PDI therefore sits above two different loss surfaces at once, the in-store register behavior aggregated across sites, and the wholesale and dealer-billing flows a pure POS integration is blind to. The store-level rule families still run on the aggregated journals; the value of tapping the ERP layer is that cross-site and back-office patterns which never touch a single register become visible from the same connection, sealed to the same independently checkable receipt.
Two honest limits: no card-entry detail, and polling cadence
Two honest limits define a PDI integration. First, PDI holds what the registers recorded and what the ERP reconciled; it does not hold how a card was read at the pump or which authorizations the network declined, so the pump-level skimmer and card-testing rules still wait on the processor authorization feed pairing in beside it. Second, PDI polls the stores on a configured cadence that ranges from frequent to daily, and observe-mode latency on the register side inherits that cadence rather than improving on it. The aggregation is the advantage; the missing card-entry detail and the polling cadence are the honest cost, and discovery states both in writing before anything is promised.
The fraud these feeds make visible
Each rule family maps to a documented, measured loss pattern in fuel and convenience retail.
The fraud PDI makes visible is the distributed kind no single store can see: a refund scheme kept under each site’s local threshold that is obvious once many stores’ journals sit in one aggregated view, the same destination card surfacing across three sites, a testing crew rotating stores nightly. Because PDI is the roll-up, that cross-site correlation comes from one connection. The pump-level card behavior still rides the processor feed, but the fleet pattern lives natively in the back office.
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
- Refund and void chains per register, per shift, per destination card — fleet-wide
- Cross-store patterns invisible to any single site’s data
- Authorization velocity and fallback divergence once the processor feed pairs in
- A sealed, independently verifiable receipt for every verdict
An integration path, not a partnership claim
PDI Enterprise is a product of PDI Technologies. RankShield Financial is an independent platform and is not affiliated with, certified by, or endorsed by PDI Technologies. This page describes RankShield’s supported integration architecture for merchants who run PDI Enterprise: 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 PDI Enterprise, 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.