Credit Card Processing for FBOs: What Every Manager Needs to Know

Credit card processing at an FBO is nothing like swiping a card at a gas station or a retail store. The aviation fueling business has its own card networks, its own authorization protocols, and its own settlement timelines. If you are running an FBO and you do not understand how these systems work, you are almost certainly leaving money on the table or exposing yourself to unnecessary risk.

I have been building FBO software since 1996, and credit card processing has always been one of the most misunderstood parts of the operation. This article breaks down what actually happens when a card is presented at your front counter.

Aviation Fuel Cards vs. Standard Credit Cards

The first thing every FBO manager needs to understand is that there are usually two different payment paths at an FBO: standard bank cards (Visa, Mastercard, Amex, Discover) and aviation fuel or contract fuel programs.

Standard credit cards usually go through the same merchant-processing ecosystem that other businesses use. Your FBO has a merchant account with a processor, and transactions move through the card brands' networks much like they would at other service businesses. The broad concepts are familiar, but your actual rates, funding timing, and chargeback exposure still depend on your processor setup and merchant agreement.

Aviation fuel cards are different. These cards are tied to fuel suppliers, contract fuel programs, or fleet purchasing arrangements. When a pilot presents one of these cards, the transaction often requires supplier-specific authorization, release, pricing, and settlement logic rather than a simple retail card flow.

This distinction matters because the authorization process, the data you need to capture, the settlement timeline, and the fee structure are all different. Your FBO software needs to handle both paths, and it needs to route each card to the correct processor automatically.

How Branded Gateways Work

Each major fuel program has its own certification requirements and transaction rules. Your POS or FBO software has to recognize the card or account type, collect the right fields, and submit the transaction through the correct path. The specifics vary by supplier and can change over time, which is why current certification and support matter more than a one-time integration claim.

Avfuel

Avfuel transactions generally require supplier-specific authorization and supporting aircraft or transaction data. Depending on the account type and program, your software may also need to account for loyalty, release, or settlement details that do not exist in ordinary retail card processing.

Phillips 66 (ConPhil)

Phillips 66 programs have their own participating-location requirements, transaction rules, and remittance workflow. The important operational point is not the transport format. It is whether your system is approved for the program you want to accept and whether staff can process those transactions without workarounds.

Titan Aviation Fuels (formerly Shell Aviation)

Titan programs can involve different account types, operational data requirements, and in some cases release or trip-specific validation. If you serve international, charter, or managed-fleet traffic, confirming what data your software captures for those programs is especially important.

World Fuel Services

World Fuel programs likewise bring their own authorization, pricing, and settlement expectations. FBOs that serve corporate, charter, or international traffic should make sure their software supports the exact World Fuel workflows they actually use, not just a generic claim of compatibility.

The Authorization and Settlement Cycle

For standard credit cards, the cycle is usually straightforward: authorize at the time of sale, capture or settle through your merchant process, and receive funding according to your processor's timeline.

For aviation fuel cards, the cycle is usually more involved. Authorization happens when the card or account is presented, but payment can depend on additional validation of pricing, aircraft eligibility, release terms, and submitted transaction data. Depending on the supplier program and your agreement, remittance may be slower or simply follow a different reporting cycle than ordinary bank-card processing.

Good FBO software tracks these different timelines and gives you visibility into what has been authorized, what has been settled, and what is still pending. Without this, reconciling your fuel card revenue becomes a manual nightmare.

PCI Compliance for FBOs

PCI DSS (Payment Card Industry Data Security Standard) applies to every business that accepts credit cards, and FBOs are no exception. The level of compliance required depends on your transaction volume and how you handle card data.

Many independent FBOs fall into PCI Level 4, which commonly means an annual Self-Assessment Questionnaire (SAQ) and, depending on the environment, external vulnerability scans. The right requirement for your operation depends on transaction volume, how cards are accepted, and whether your systems store, transmit, or can affect the security of cardholder data.

The biggest PCI risk at FBOs is card data storage. If your software stores full card numbers, you are in a much higher compliance category. Modern FBO software uses tokenization, where the actual card number is replaced with a token that can only be used by your specific system. This dramatically reduces your PCI scope.

Cards on file - where you store a customer's card for repeat billing - must use tokenization. You should never have full card numbers sitting in your database. If your current software stores card numbers in plain text, that is a serious problem that needs to be addressed immediately.

Surcharging: What You Can and Cannot Do

Credit card surcharging is an area where rules change and exceptions matter. Whether you can surcharge, which card types are eligible, how the fee must be disclosed, and what cap applies can depend on state law, card-brand rules, your processor agreement, and whether the payment is truly a credit transaction or a debit transaction. Treat this as a compliance setup project, not just a pricing toggle.

For FBOs, surcharging comes up because processing fees on large fuel transactions can be significant. If you choose to use it, your software should apply it only where permitted, separate it clearly on the invoice, and support whatever disclosures your processor and jurisdiction require.

Many aviation fuel and fleet programs are handled differently from ordinary retail card transactions, so you should not assume they are surcharge-eligible. Your software needs to distinguish eligible and non-eligible payment types based on your actual processor and supplier rules.

Common Problems and How to Avoid Them

Batch Settlement Failures

If your batch does not settle properly, you do not get paid. Common causes include network timeouts, mismatched transaction totals, and expired authorizations. Your software should alert you when a batch fails and make it easy to resubmit.

Chargebacks

Aviation fuel card chargebacks usually happen when the transaction data does not match the contract terms - wrong pricing, missing tail number, or unauthorized fueling. Capturing complete and accurate data at the time of sale is your best defense.

Duplicate Transactions

Double-submitting a payment is easier than you think, especially during busy periods. Your POS system should have protections against duplicate submissions, such as submission tokens that prevent the same transaction from being processed twice.

Stale Authorizations

An authorization has a limited lifespan. If you authorize a transaction but do not settle or complete it within the allowed window, you may create collection or reconciliation problems. The exact timing varies by card brand, processor, supplier program, and transaction type.

Choosing the Right Setup for Your FBO

The ideal credit card processing setup for an FBO integrates standard card processing and all of your fuel card brands into a single system. You should not need to use one terminal for Visa/Mastercard, another system for Avfuel, and a phone call for Shell. Everything should flow through your FBO software with the card type detected automatically and routed to the correct processor.

Look for software that supports tokenization for cards on file, automatic surcharge calculation, batch settlement with error reporting, and clear reporting that separates standard card revenue from fuel card revenue. Your accountant will thank you.

Frequently Asked Questions