# RankShield Integration Path: Heartland-Processed Merchants | RankShield Financial > How RankShield Financial adds store-level fraud detection for merchants on Global Payments and Heartland processing — convenience, fuel, and restaurant fleets, observe-first. > > Source: https://rankshieldfinancial.com/integrations/global-payments-heartland/ · RankShield Financial (verifiable pre-settlement payment security) Integration path · Processors & acquirers # Fleet fraud intelligence beside Global Payments and Heartland processing. For merchants processing with Global Payments or its Heartland lineage — a footprint that runs deep in convenience stores, petroleum, and restaurants — RankShield consumes the authorization detail and settlement reporting the merchant relationship already produces, builds per-terminal baselines across the fleet, and seals every verdict to the RankShield Network from a position entirely outside the payment path. Request a pilot See the industry page feeds-only observe-first fail-safe: payments flow The integration position Payment path untouched — never proxied Store hardware nothing installed Data consumed journal + processor reporting Default state observe · fail-safe serve 01 // the stack Where the data already lives ## A processor lineage that maps to our strongest rules Heartland built much of its franchise in exactly the merchant classes where store-level fraud concentrates: convenience stores, fuel, and restaurants. Those environments share a profile — unattended or semi-attended terminals, high card-present volume, register refund flows, thin loss-prevention staffing — and it is the profile RankShield’s rule families were built for. The authorization detail and settlement reporting a Global Payments merchant receives carries the terminal identity, entry mode, and decline visibility those rules run on. The position ## The integration position, unchanged RankShield is a designated recipient of merchant reporting — never a hop in the authorization path, never software on the terminal. Scoring, baselining, and fleet correlation run on our side; responses are operational and sealed with verifiable receipts. Restaurants on the same processing relationship fold into the same fleet view with rules weighted for their risk surface: card-present velocity, refund and void abuse, and tip-adjustment anomalies rather than fuel-position divergence. 02 // tap points Where RankShield reads ## Three tap points, zero store changes Each feed already exists at the site. The integration directs it to one additional recipient you control. ### Authorization detail approvals AND declines Terminal-level auth records with entry mode — powering velocity, fallback-divergence, and testing-burst detection. ### Settlement & dispute files money-truth & evidence Settlement data reconciles scored versus settled; dispute records feed sealed evidence packs for chargeback response. ### POS journal pairing register & shift detail Store journal feeds add the refund, void, cashier, and shift detail that acquirer data cannot see. 03 // under the hood Under the hood ## What Heartland reporting means after the mergers Global Payments is an assembly of Heartland, TSYS Merchant Solutions, and Global own book, so which brand a merchant boarded through decides what its reporting looks like. **On this stack specifically:** Mixed portfolios are the norm here — a convenience fleet with fuel at some sites and food service at others. Terminal classes get separate baselines and rule weights; the fleet view and the sealed-receipt discipline stay uniform. ### One processor, many legacy brands Global Payments bought Heartland in 2016 and merged with TSYS in 2019, folding TSYS Merchant Solutions into the Heartland brand, so a merchant processing with Heartland today may sit on any of several inherited platforms. That sprawl is the defining reporting fact here: authorization and settlement extracts differ in layout and field availability depending on which legacy brand and platform the account was boarded through. The integration adapts to that at intake rather than pretending it away, and discovery first job is to identify which platform your account actually lives on. Downstream, the per-terminal baselines and sealed receipts are identical regardless of the brand printed on the statement. ### A merchant book built for the register rules Heartland built its franchise in convenience, fuel, and restaurants, the environments where store-level fraud concentrates: unattended or semi-attended terminals, high card-present volume, register refund flows, and thin loss-prevention staffing. That is the exact profile the register and terminal rule families were written for. A Global Payments or Heartland merchant authorization reporting carries the terminal identity, entry mode, and decline visibility those rules run on, and when the POS journal pairs in, the register-level refund, void, and adjustment detail completes the picture. Restaurants on the same relationship fold into one fleet view, with rules weighted toward card-present velocity and adjustment anomalies rather than fuel-position divergence. ### The Worldpay combination on the horizon The honest forward-looking note is that Global Payments has agreed to combine with Worldpay, a move that would place two of the largest acquiring books under one roof and set off exactly the kind of platform migration that strands fraud coverage tied to a single processor. RankShield position is unchanged by any of it: because the integration normalizes authorization detail into one per-terminal stream regardless of which platform emits it, a merchant moved between Heartland, TSYS, and Worldpay lineages keeps one fraud view and one sealed-receipt history across the transition. Processor consolidation is an argument for holding your evidence outside the processor, not inside it. 04 // what it surfaces What it surfaces ## The fraud processor data makes visible The rule families map to documented, measured loss patterns — and to the specific signals only the authorization feed carries. $428M in potential skimming losses the U.S. Secret Service estimated it prevented in a 2025 crackdown (411 devices, 9,000+ businesses) 4 $3.05B reported U.S. business email compromise losses in 2025 — context for why settlement-side verification and evidence matter (FBI IC3) 5 Heartland’s convenience-and-restaurant book bleeds two ways at once. At c-stores and fuel it is card-testing and skimmer fallback in the authorization detail; in restaurants it is register disbursement fraud, refund and void chains and tip adjustments per server and shift, which live in the POS journal the acquirer never sees. A franchise group running both needs the two feeds correlated, because each half of the estate hides a different pattern, and only the paired view resolves both against each terminal’s own baseline. 05 // check your readiness An honest two-minute read ## Is your processor reporting ready? Each question maps to a feed or control this integration depends on. The tally runs in your browser — nothing is transmitted. - 01 Does your merchant agreement provide authorization-detail reporting, not just settlement totals? - 02 Does that reporting include declined authorizations and card-entry mode? - 03 Do you have a mapping of terminal IDs to specific stores and lanes? - 04 Do you receive settlement and chargeback files you could redirect to a recipient? - 05 Do you process across more than one acquirer or platform? Answer all 5 to see where you stand · 0/5 06 // rollout Observe first, enforce when earned ## 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. WEEK 1 ### 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. WEEKS 2–4 ### 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. GO-LIVE ### 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?” 07 // what we verify The rule families ## What the rail watches on this stack - Authorization velocity per terminal, including decline-heavy bursts - Entry-mode divergence per fuel position at petroleum sites - Refund, void, and adjustment chains per register and per shift - A sealed, independently verifiable receipt for every verdict Independence, stated plainly ## An integration path, not a partnership claim Global Payments / Heartland is a product of Global Payments. RankShield Financial is an independent platform and is not affiliated with, certified by, or endorsed by Global Payments. This page describes RankShield’s supported integration architecture for merchants who run Global Payments / Heartland: 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](https://rankshieldfinancial.com/transparency/). Primary sources ## 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. - [ISO — ISO 8583 financial-transaction card messaging standard](https://www.iso.org/standard/31628.html) - [PCI Security Standards Council — PCI DSS](https://www.pcisecuritystandards.org/) - [EMVCo — EMV chip specifications (governing body)](https://www.emvco.com/) - [U.S. Secret Service — Nationwide Crackdown on Card Skimming and Fraud](https://www.secretservice.gov/newsroom/behind-the-shades/2026/01/inside-our-nationwide-crackdown-card-skimming-and-fraud) - [FBI IC3 — 2025 Internet Crime Report](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf) - [Visa — Anti-Enumeration and Account Testing Best Practices](https://usa.visa.com/support/small-business/security-compliance.html) FAQ ## Integrating beside Global Payments / Heartland, answered Every question buyers ask before they trust a payment-security platform, answered directly. JAMIE KLONCZ · RANKSHIELD FINANCIAL ONLINE Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it. REQUEST ACCESS → The rest of the stack ## Other integration paths Fiserv Worldpay Chase Payment Solutions Elavon Shift4 Gilbarco Passport All integrations See the full fuel & convenience picture Verify, then settle ## 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. Request a pilot How it works ## Frequently asked questions ### Our franchise group runs c-stores and restaurants on Heartland. One deployment or two? One. The integration consumes the same two feed classes for both — authorization detail from the processing relationship and journal data from the POS layer — and the difference lives in rule weighting, not architecture. Convenience and fuel terminals get overnight-velocity and entry-mode rules; restaurant terminals get card-present velocity, refund and void chains, and adjustment-anomaly rules. The operator sees one fleet view with per-class baselines, and every verdict from either side carries the same independently verifiable receipt. Adding a new location, of either kind, is a terminal-mapping entry rather than a new project. ### Is this a Global Payments partnership? No. Global Payments and Heartland are named because operators ask the practical compatibility question and deserve a direct answer. RankShield Financial is an independent platform — not affiliated with, certified by, or endorsed by Global Payments. The integration runs on merchant-directed reporting: data your agreement already generates, sent where you choose. We keep this discipline on every processor page for the same reason our verdicts carry receipts: a fraud vendor’s claims should be verifiable, starting with its claims about itself. ### What is the very first step? A short discovery: confirm which reporting tier your merchant agreement provides, its cadence, and who administers your POS journals — for a franchise group, often three answers from one operations lead. Then the data-access agreement, then the Phase-1 historical baseline: sixty to ninety days of your own data through the full rule set, delivered as a findings report showing exactly what would have been flagged, where. Stores are never visited, terminals are never touched, and nothing is enforced until observe mode on live traffic has proven the accuracy of what the baseline found. ### Our franchise group is on Heartland. Who do we involve? Usually one operations lead can answer the Phase 0 discovery: which reporting tier your Global Payments or Heartland agreement provides, its cadence, and who administers your POS journals. For a franchise group those are often three answers from one person, followed by a data-access agreement and the historical baseline. Stores are not visited and terminals are not touched to produce the first findings report. ### Do restaurants and c-stores on Heartland deploy together? One deployment. The integration consumes the same two feed classes for both, and the difference is rule weighting rather than architecture: convenience and fuel terminals get overnight-velocity and entry-mode rules, restaurant terminals get card-present velocity, refund and void chains, and adjustment-anomaly rules. The operator sees one fleet view with per-class baselines, and adding a location of either kind is a terminal-mapping entry.