Why FANF Can Hit Twice the Month You Switch Processors and How to Time the Cutover

Switching payment processors can create an unusual month in which a merchant sees what appears to be the same Visa network fee from two different providers. 

If you are investigating FANF charged twice switching processors, the first question should not be, “Which processor made the mistake?” It should be, “Did two separate acquiring relationships handle Visa activity during the same assessment period?”

That distinction matters. Processor A and Processor B do not ordinarily operate as a single billing system. Each processor or acquiring relationship reports and bills activity according to its own agreement, merchant configuration, Visa activity, and billing process. 

If the old relationship handles Visa transactions during one part of a month and the new relationship handles them during another, each relationship may generate FANF-related charges under the applicable Visa structure.

That does not mean duplicate FANF happens on every migration, or that two charges are automatically correct. Card-present and card-not-present activity need to be examined separately, and each statement must be reconciled against the merchant’s actual activity and current Visa rules.

For merchants with flexibility, moving new sales close to a clean month boundary can reduce unnecessary overlap. But FANF should never be the only consideration. 

Refunds, disputes, recurring credentials, settlement, processor billing lag, statement access, and operational readiness can make an overly aggressive account closure more expensive than the network fee you were trying to avoid.

Why FANF Can Be Charged Twice During a Processor Switch

The critical fact about a processor migration is that the old and new accounts are separate commercial and acquiring relationships.

Visa describes merchants as negotiating processing services and merchant pricing with their acquirer, and Visa’s public rules recognize that acquirers independently establish merchant service pricing. 

Before signing a new processing agreement, Visa specifically advises merchants to identify the acquirer named in the contract and compare rates and fees.

That relationship structure explains why a duplicate FANF processor switch can occur.

Consider this migration:

• Processor A remains the merchant’s active processor through June 14.
• Processor B begins handling sales on June 15.
• Both processors handle Visa activity during June.
• Processor A later produces a statement containing FANF-related network charges for activity attributed to its relationship.
• Processor B produces a separate statement containing FANF-related charges for the new relationship.

The merchant sees two charges associated with one calendar month, but Processor B does not normally look at Processor A’s statement and subtract whatever Processor A billed. Nor should the merchant assume that Processor A’s assessment automatically covers activity reported by Processor B.

This is the operational meaning of double FANF two acquirers: two separately administered processing relationships overlap during a migration period.

Whether the exact FANF amount on either account is appropriate still depends on factors such as merchant channel, merchant classification, active locations or applicable CNP volume treatment, processor configuration, and Visa rules in effect for the period.

Split-Month FANF Example

Period	Processor	Channel	Visa Activity	FANF Exposure
June 1–14	Processor A	Card-present	Normal store activity	Old acquirer may have FANF-related exposure for June
June 15–30	Processor B	Card-present	Same stores after migration	New acquirer may separately have FANF-related exposure
June 1–14	Processor A	CNP	Ecommerce orders	Volume belongs to old processing relationship for reconciliation
June 15–30	Processor B	CNP	Ecommerce orders	Volume belongs to new relationship for reconciliation

The table deliberately avoids assigning a dollar amount. The important point is the existence of two processing relationships, not a claim that every split-month migration creates exactly two equal FANF charges.

Before estimating a transition month, finance teams should first confirm how card-present and card-not-present FANF are calculated and then apply the current processor-specific fee schedules to the migration.

Why one processor does not offset the other

A processor transition is not like transferring money between two departments of the same company.

Processor A generally bills the merchant under Processor A’s contract. Processor B bills under Processor B’s contract. The processors may have different sponsoring acquirers, merchant IDs, statement formats, billing calendars, markups, minimums, or bundled pricing.

Therefore, when reviewing old and new acquirer FANF, never start with this assumption:

“The new processor should know the old processor already charged us.”

Instead, ask each processor what activity, merchant IDs, locations, volume, period, and network assessment produced its line item.

That creates an auditable explanation rather than a guess.

Card-Present vs Card-Not-Present FANF in a Split Month

Card-present and card-not-present merchants should not model a processor switch the same way.

Historical and processor documentation for FANF has distinguished card-present treatment based substantially on active processing locations and merchant classification from card-not-present treatment tied to monthly Visa sales volume. 

A first-party TSYS merchant program guide, for example, describes CP calculations using active merchant locations and CNP calculations using gross Visa sales volume, while Worldpay’s current reporting documentation continues to identify FANF tier descriptions and monthly Visa settled sales volume in its merchant FANF reporting.

Because Visa’s publicly accessible rules do not provide a reliable current merchant-facing table of FANF dollar amounts, merchants should obtain the current schedule applicable to their acquiring relationship rather than relying on historical online rate tables.

For planning purposes, however, the distinction between location-driven CP exposure and volume-driven CNP exposure remains essential.

Channel	What Drives the FANF Review	Split-Month Risk	What to Verify
Card-present	Merchant classification, active processing locations and applicable Visa structure	Same physical footprint may appear under two acquiring relationships during the month	Location count, merchant IDs, MCC, active dates
Card-not-present	Visa sales volume and applicable monthly tier treatment	Monthly volume is divided between old and new relationships	Visa volume on each account and tier used
Mixed CP/CNP	Both sets of mechanics can matter	Migration can affect each channel differently	CP location setup and CNP volume separately
Multi-location	Number and organization of locations matter	Staged migration can extend overlap	Which locations were active with each acquirer

For businesses managing dozens or hundreds of locations, it is especially important to maintain an inventory of merchant IDs and locations. The relationship between locations and FANF is explored further in FANF for multi-location merchants.

Card-present split-month FANF

Suppose a retailer has 12 stores.

All 12 process on Processor A through the 14th. The company then reroutes all stores to Processor B on the 15th.

Operationally, the company may think, “We still have 12 stores, so we should have one monthly location-based cost.”

From the acquiring side, however, the month contains two distinct configurations:

Date Range	Processor	Locations	Visa Activity	FANF Exposure
July 1–14	Processor A	12	Visa sales at all stores	Review old acquirer assessment for active CP locations
July 15–31	Processor B	12	Visa sales at all stores	Review new acquirer assessment separately

This does not establish that Visa necessarily charges the merchant twice for precisely the same item in every configuration. It illustrates why both processors can have a basis for reporting network costs associated with an active merchant relationship in the same month.

The finance team’s job is to validate the old and new statements independently.

Check:

1. Which merchant IDs were active?
2. Which locations were associated with them?
3. What dates processed Visa sales?
4. What MCC or merchant classification was submitted?
5. What FANF treatment did each processor apply?
6. Was anything bundled or marked up?

A useful companion for complex footprints is forecasting FANF for multi-location businesses.

Card-not-present split-month FANF

A CNP transition has a different reconciliation problem.

Suppose an ecommerce company processes hypothetical Visa sales volume of V₁ during the first half of the month with Processor A and V₂ during the second half with Processor B.

Do not automatically add V₁ + V₂, look at a FANF tier table, and assume that is what both processors should have billed collectively.

The transaction populations traveled through two relationships.

The safer audit is:

Processor A: compare V₁ with the FANF treatment applied to Processor A.

Processor B: compare V₂ with the FANF treatment applied to Processor B.

Then compare:

Actual transition cost = Processor A FANF-related cost + Processor B FANF-related cost

against a hypothetical steady-state month under one acquiring relationship.

This is particularly important when volume near a tier boundary is divided between providers. Two separate monthly calculations can create a different economic result from one steady-state monthly volume calculation.

Visa’s public materials establish the central role of the acquirer, while Worldpay’s first-party FANF reporting documentation explicitly includes merchant monthly Visa settled sales volume and a FANF tier description.

For ecommerce teams, card-not-present FANF and the factors that can move a tier provides useful background before building a cutover model.

Seasonal or high-volume ecommerce example

Assume an online merchant normally processes an entire month’s Visa activity with one provider.

During migration month:

• Days 1–16 run through Processor A.
• Days 17–month-end run through Processor B.
• Both relationships therefore record only a portion of the merchant’s normal monthly volume.

Now compare three figures:

Normal month

FANF treatment based on full qualifying Visa activity through one relationship

Migration month

Processor A treatment based on its reported activity
+
Processor B treatment based on its reported activity

Following month

FANF treatment based on full activity through Processor B

Do not assume the migration-month total will equal the normal-month figure. It may be higher, lower, or simply structured differently depending on the applicable rules and processor billing.

The migration model should therefore use the current schedules supplied by both processors rather than historical figures copied from an article.

Is a Month-Boundary Cutover Cheaper?

Often, the cleanest processor cutover is one in which Processor A handles the outgoing month and Processor B begins handling new sales at the start of the next month.

That arrangement can reduce the likelihood of having meaningful Visa sales under both relationships in the same calendar month. It also makes statements easier to reconcile.

But “switch on the first” is not a universal FANF loophole.

Three dates can differ:

• the customer transaction date,
• processor settlement or reporting date,
• the period to which a network assessment or processor charge is attributed.

A batch accepted close to month-end may not produce a perfectly clean accounting split merely because a terminal was reconfigured at midnight.

Mid-month versus month-boundary cutover

Timing	Fee Overlap Risk	Operational Risk	Best Use
Mid-month	Higher potential for two active processing relationships in one month	Often easier to staff and troubleshoot	When deployment readiness matters more than fixed-fee overlap
Near month-end	Can reduce overlap if transactions and reporting separate cleanly	High if migration occurs during a busy closing period	Stable environments with strong rollback/testing plans
First days of new month	Cleaner month-to-month separation	Requires careful handling of prior-period batches	Merchants able to schedule a controlled launch
Staged across locations	May extend overlap	Lower implementation risk per location	Large estates where operational safety requires gradual deployment

A useful cutover cost model

Instead of asking only, “Will FANF double?” calculate:

Transition-month cost = old processor network/fixed fees + new processor network/fixed fees + migration-specific costs

Migration-specific costs can include items such as:

• terminal deployment;
• gateway overlap;
• software subscriptions;
• implementation charges;
• monthly minimums;
• statement or account fees;
• PCI-related charges where contractually applicable;
• contract termination costs;
• staff or integration work.

This is where switching payment processors network fees becomes broader than FANF.

FANF is one specific Visa network assessment. It should not be combined indiscriminately with interchange, Visa transaction assessments, statement fees, gateway subscriptions, processor markup, minimums, equipment leases, or dispute fees.

When waiting for the month boundary may make sense

Waiting several days can be financially rational when:

• a merchant has a large location footprint;
• material CNP volumes fall into meaningful FANF tiers;
• both processors impose other fixed monthly charges;
• the current processor is stable;
• the new system has already passed testing;
• there is no contractual or security reason requiring an earlier move.

In those circumstances, processor cutover timing fees become part of a legitimate migration decision.

For example, consider two hypothetical alternatives:

Scenario A — Mid-month

Old processor fixed/network costs

• new processor fixed/network costs
• migration costs

Scenario B — Month boundary

Outgoing month’s normal old-processor costs

• next month’s normal new-processor costs
• migration costs

The second structure may reduce duplicated fixed monthly exposure, but only actual fee schedules can establish whether the difference is material.

When waiting is not worth it

Do not postpone a necessary migration solely to chase a FANF saving when:

• the incumbent service is unreliable;
• a security issue requires urgent action;
• the merchant faces a contractual deadline;
• critical ecommerce functions are failing;
• authorization performance is damaging revenue;
• operational costs of waiting exceed the likely network-fee overlap.

A payment outage can cost far more than one transition month’s FANF difference.

Avoid a last-minute midnight cutover

Month-end is attractive for accounting, but 11:58 p.m. on the last day of the month is not automatically good operations.

Leave enough time to validate:

• live authorization;
• capture;
• settlement;
• correct merchant descriptor;
• tip or adjustment workflows;
• ecommerce callbacks;
• recurring billing;
• reporting;
• funding.

A controlled cutover a little earlier may be superior to a theoretically perfect calendar boundary with no troubleshooting window.

What the Old Processor’s Final FANF Statement Should Show

The phrase FANF final statement old processor can be misleading because merchants sometimes expect a closing statement to contain only sales from the final few days.

In reality, a final or later statement can include several categories.

Old final statement audit

Charge	Expected?	Reason	Follow-Up
FANF tied to final active processing period	Potentially	Final Visa activity may create an applicable network assessment	Match to activity and current rules
Other Visa/network assessments	Potentially	Transaction activity can create distinct network charges	Do not confuse with FANF
Processor monthly fee	Depends on agreement	Fixed contractual billing may apply through a defined date	Check contract and closure date
Gateway/software fee	Depends	Service may remain active separately from acquiring	Confirm vendor termination
Refund-related charge	Potentially	Legacy transactions may still be refunded	Reconcile refund
Chargeback/dispute charge	Potentially	Old transactions remain subject to disputes	Match to dispute case
Termination/closure charge	Contract-specific	May arise under merchant agreement	Request contractual basis
Unidentified “network” charge	Needs review	Label may not prove exact assessment	Request fee-level explanation

A charge posted after you stop sending new transactions is not automatically a billing error.

Processors and platforms can have adjustments that post after the original transaction period. Stripe’s first-party network-cost reporting documentation, for example, notes that some network-cost values can be revised after the original transaction month and identifies FANF as a non-transactional card-network cost in its reporting framework.

That example should not be generalized into a universal delay for all processors. It simply demonstrates why “posted after cutoff” and “invalid” are not synonyms.

For help separating labels on a statement, see where FANF may appear on merchant statements.

Why Trailing Fees Can Appear After the Account Is Closed

Trailing fees after closing merchant account can arise for several reasons:

• the charge relates to the final processing period;
• a network assessment was posted or adjusted later;
• a refund occurred;
• a dispute or chargeback was processed;
• a contractual account charge remained due through the termination date;
• another product, gateway, terminal or software service had its own cancellation status.

There is no responsible universal answer to “How many months can this continue?”

The answer depends on the merchant agreement, statement cycle, transaction history, network posting, refund activity, dispute activity, and the particular services the merchant had enabled.

Get the old processor to answer in writing:

1. What is our contractual closure date?
2. What is the last date on which fixed account charges can be assessed?
3. Which network charges can post after new sales stop?
4. Will we receive statements if the net amount is zero?
5. How are refunds billed?
6. How are post-cutover disputes billed?
7. Are any software, gateway, terminal or compliance services terminated separately?

Chargeback tail and FANF tail are not the same thing

This distinction prevents a lot of confusion.

A FANF tail refers to later billing associated with FANF or related accounting for an earlier processing period.

A chargeback tail is the continuing possibility that a cardholder dispute involving an old transaction will be routed through the processor/acquirer that originally handled the transaction.

Visa describes a dispute as a reversal initiated by the issuer to the acquirer and generally onward through the merchant bank to the merchant. Visa also instructs merchants to respond through the acquirer or processor handling the dispute.

So a merchant can have no new Visa sales on the old processor and still need the old processor for dispute administration.

Do not interpret a later chargeback as evidence that the old processor is still handling ordinary new sales.

How to Keep the Old Account Available for Refunds and Chargebacks

Closing the old account immediately after the last sale can create operational problems.

A refund generally needs to connect back to the original payment record. Stored payment credentials, transaction references, gateway tokens, processor tokens, or refund permissions may remain tied to the old platform.

That is why processor migration has two separate routing questions:

Where do new authorizations go?

and

How are legacy refunds and disputes handled?

Those questions should have different answers after cutover.

Refund/chargeback tail planning

Function	Old Processor Needed?	How Long?	What to Confirm
New sales	Normally no after completed cutover	N/A	Exact new-sale shutdown date
Refunds on old transactions	May be	Contract/platform dependent	Whether legacy refunds remain possible
Chargeback responses	Usually requires old relationship or portal	Case dependent	Portal and documentation access
Historical statements	Often operationally necessary	Business-record requirements	Export/archive method
Settlement research	May be necessary	Until reconciliation is complete	Reporting access
Recurring tokens	Depends on portability	Migration dependent	Ownership, export and mapping
New refunds on new sales	New processor	Ongoing	New gateway/refund workflow

No universal rule says every processor offers “refund-only mode.”

Some environments can stop normal sales while preserving some ability to process returns against prior transactions. Other processors use different closure procedures.

Ask before cutting over.

Can keeping the old account open trigger another FANF cycle?

Potentially, but do not oversimplify this into “an open account always causes FANF.”

What matters is the merchant’s actual Visa activity, processor configuration and the applicable FANF rules.

A safer operational objective is:

• stop routing new sales to the old account;
• disable old checkout routing;
• remove or restrict legacy terminals;
• revoke unnecessary credentials;
• preserve only the access needed for refunds, reporting and disputes where supported.

This reduces the risk of an employee, integration, retry job or forgotten terminal accidentally submitting new Visa sales on the legacy account.

Do not claim that a refund itself necessarily triggers FANF. That conclusion should come only from the applicable network and processor treatment for the merchant’s circumstances.

Token and recurring billing migration

Recurring merchants need additional preparation.

A gateway token created under Processor A may not automatically work under Processor B. Network tokens, gateway vault tokens and raw stored credentials are not interchangeable concepts.

Before migration, identify:

• who owns the token vault;
• whether credentials can be exported;
• whether network tokens can be transferred or reprovisioned;
• whether customer re-entry is required;
• how recurring authorizations will transition;
• which system handles refunds for pre-migration transactions.

The goal is to prevent a FANF optimization exercise from creating involuntary churn or failed recurring charges.

Safe old-account closure sequence

Use this order:

1. Stop routing new sales to the old processor.
2. Verify the last expected batch settled.
3. Export settlement, transaction and statement records.
4. Confirm the refund workflow for old transactions.
5. Confirm continuing chargeback/dispute access.
6. Confirm the contractual closure date.
7. Obtain a written description of residual charges.
8. Restrict legacy terminals, gateways and credentials against accidental new sales.
9. Continue reviewing any legitimate residual statements.
10. Archive the final reconciliation.

What to Ask the New Processor Before Signing

The cheapest time to investigate FANF treatment is before the processing agreement is executed.

Visa’s public guidance emphasizes comparing acquirer fees and identifying the acquirer named in the processing agreement.

Ask the new processor these questions in writing:

1. How is Visa FANF passed through to us?
2. Is FANF passed at network cost, bundled, or marked up?
3. Does FANF appear as a separate statement line?
4. How are our card-present locations counted?
5. Which merchant IDs and taxpayer identifiers will be used?
6. How are CNP FANF tiers applied to our Visa volume?
7. How will the first partial processing month be handled?
8. Are there monthly minimums in addition to FANF?
9. What statement, gateway, software, PCI or account fees apply?
10. Are any first-month charges prorated?
11. How will refunds from the previous processor be handled?
12. How will chargebacks involving old transactions be handled?
13. Can stored credentials or tokens be migrated?
14. Who owns the token vault?
15. What fees would continue if this new account were later closed?

The response to Question 2 is particularly important.

FANF pass-through versus processor markup

Visa FANF and processor pricing are different economic layers.

A processor may:

• pass a network fee through separately;
• incorporate it into another network-cost category;
• bundle network expenses into a broader pricing structure;
• apply contractual markup around network costs.

Therefore, a statement saying “Visa Network Fee” does not, by itself, establish that the amount exactly equals Visa’s underlying assessment.

Conversely, a high-looking effective rate does not prove FANF was marked up.

Request the calculation.

For finance teams that want to separate the two layers, validating FANF against processor markup provides a useful audit framework even outside high-ticket retail.

Ask the old processor too

Get written answers from Processor A before issuing final closure instructions:

• What date will you stop accepting new sales?
• What is our formal account-termination date?
• Which network costs can appear after that date?
• How will remaining refunds be processed?
• Will we retain dispute-portal access?
• Will historical statements remain downloadable?
• Which monthly fees can continue after new sales stop?
• Are the gateway and merchant account terminated separately?
• Will any reserve, balance adjustment or chargeback debit continue through a separate process?
• To whom should unexplained residual charges be escalated?

Verbal assurances are poor evidence during a billing dispute. Email or contract language is better.

How to Audit the First New-Account Statement

The first statement from Processor B deserves more scrutiny than a normal monthly statement.

The merchant’s setup is new. The merchant IDs are new. Location configuration may be new. Pricing may be new. CNP routing may have changed. And the first month may contain only partial-month activity.

An incorrect FANF line can therefore be a symptom of a configuration problem rather than merely an isolated fee issue.

First new-statement audit

Item	Expected	Actual	Variance	Follow-Up
FANF treatment	Per signed pricing/current structure	Statement result	Calculate	Request calculation if different
CP location count	Verified active locations	Processor count	Calculate	Correct location mapping
CNP Visa volume	Exported Visa sales	Volume processor used	Calculate	Reconcile settlement files
CNP tier	Tier expected from applicable schedule	Tier billed	Compare	Request tier basis
MCC/classification	Underwritten merchant profile	Statement/backend profile	Compare	Correct miscoding
Monthly fixed fees	Signed agreement	Statement	Calculate	Challenge unsupported fee
Processor markup	Proposal/Schedule A	Actual	Calculate	Request contract correction
Proration	Written commitment, if any	Actual treatment	Compare	Obtain explanation

Verify the card-present location count

For CP merchants, build a location inventory before reviewing the fee.

Include:

• legal entity;
• taxpayer identifier;
• store/location;
• merchant ID;
• terminal/gateway;
• processor;
• first live date;
• last legacy transaction date.

Then compare that inventory with the count or merchant organization the processor says it used.

Pay particular attention after acquisitions, store closures, pop-ups, concessions, franchises and staged rollouts. A terminal removed from the counter does not necessarily prove the underlying merchant configuration was updated.

Verify the CNP tier

For a CNP merchant:

1. Export the month’s transactions from Processor B.
2. Isolate Visa activity relevant to the FANF calculation.
3. Reconcile that activity to settled reporting.
4. Obtain the current FANF tier schedule used by Processor B.
5. Identify the tier the processor says applies.
6. Recalculate the expected assessment.
7. Compare it to the statement.
8. Request an explanation for any variance.

Do not use total card volume across Visa, Mastercard, Amex and Discover as the denominator.

Also do not assume Processor A’s partial-month Visa volume should have been added to Processor B’s volume unless the applicable Visa/acquirer treatment explicitly requires that aggregation for your configuration.

Compare the first statement to underwriting and the proposal

Sales presentations are not enough.

Keep:

• signed processing agreement;
• pricing schedule;
• amendment;
• email confirming FANF treatment;
• location schedule;
• gateway proposal;
• deployment plan.

When the first statement arrives, match every recurring or network-related category to documentation.

A processor might accurately pass through FANF while simultaneously billing an unexpected gateway, minimum or statement fee. Those are separate findings.

Do not use only the effective rate

A single effective-rate calculation is useful for trend monitoring but weak for diagnosing FANF.

For example:

Total processing fees ÷ total sales = effective rate

An unexpectedly high effective rate tells you to investigate. It does not identify the cause.

The cause might be:

• card mix;
• interchange qualification;
• cross-border activity;
• network assessments;
• FANF;
• monthly minimums;
• processor markup;
• equipment fees;
• disputes;
• gateway charges.

Audit the fee-level detail.

Multi-Location and Ecommerce Cutovers Need Extra Planning

A single-location merchant can often switch routing in one controlled event.

A 200-location chain may prefer a staged deployment.

That can reduce operational risk but extend the FANF overlap.

For example:

• 50 stores move in August;
• another 75 move in September;
• the final 75 move in October.

Processor A and Processor B may both remain meaningfully active for multiple assessment months.

The organization should model the cost of that longer overlap against the operational risk of an all-at-once migration.

Neither strategy is universally correct.

Staged cutover risk

Staged migration is often attractive because:

• support teams can concentrate on fewer sites;
• terminal issues are contained;
• training happens in waves;
• rollback is easier.

But the cost model should recognize:

• longer processor overlap;
• parallel gateway/software charges;
• fixed account costs;
• possible CP FANF overlap;
• more complex reconciliation.

Ecommerce cutover risk

Ecommerce migrations have their own short-overlap causes:

• DNS or endpoint changes;
• gateway routing;
• checkout version deployment;
• token migration;
• subscription retries;
• webhook transition;
• traffic gradually moving between systems.

Even a planned one-hour overlap can result in transactions at both processors.

That does not mean the migration failed. It means finance must reconcile both relationships.

New sale routing and legacy refund routing should also be deliberately separated. Once Processor B is live, new authorizations should follow the intended new route, while Processor A should remain available only to the extent required for old transactions.

Common FANF Mistakes During a Processor Migration

Several mistakes repeatedly create confusion around merchant account cutover fees.

Assuming old FANF ends the moment sales stop

Stopping sales at noon does not prove every network cost associated with that relationship disappears at noon.

Reconcile the charge to the activity period before disputing it.

Assuming the new processor prorates automatically

Do not assume a fixed or network-related fee will be prorated because the merchant processed only half a month.

Ask before signing how partial months are handled.

Switching mid-month without a fee model

Operational teams often choose a launch date while finance learns about it afterward.

Model both a mid-month and month-boundary scenario before deployment.

Closing old portal access immediately

The old environment may contain statements, refund functions and dispute records that remain important after new sales stop.

Export data and establish continuing access first.

Leaving legacy terminals active

An employee can accidentally run a sale through an old terminal weeks after migration.

Disable or restrict old-sale functionality where the processor supports it.

Calling every trailing fee a duplicate

A trailing network assessment, dispute charge and processor monthly fee can all appear after migration for different reasons.

Reconcile the line item before classifying it.

Failing to audit the first CNP tier

The new processor may have only partial-month volume. Confirm the tier treatment instead of assuming it matches the old account.

Failing to audit CP locations

Incorrect location counts can distort FANF-related billing.

Accepting verbal fee promises

“FANF is passed through” is too vague.

Ask what “pass-through” means, how the fee appears, whether it is marked up and how partial months work.

Mistake	Risk	Better Approach
Assume old FANF stopped instantly	Valid residual cost mistaken for error	Match charge to activity/assessment period
Assume automatic proration	Unexpected first-month charge	Obtain partial-month policy in writing
Switch mid-month without modeling	Avoidable fixed/network overlap	Compare cutover scenarios beforehand
Close portal access early	Lost refund/dispute/reporting access	Archive and preserve required access
Leave old terminal usable	Accidental legacy transactions	Disable new-sale functionality
Call all trailing charges duplicates	Incorrect disputes with processor	Categorize every charge first
Ignore first CNP tier	Misbilling goes unnoticed	Reconcile Visa volume and tier
Ignore CP locations	Incorrect location basis persists	Maintain location/MID inventory
Rely on verbal promises	Difficult fee dispute	Preserve signed/written pricing

Processor Cutover FANF Checklist

Use this workflow before, during and after migration.

Before choosing the cutover date

1. Pull the current Visa FANF rules and processor-specific FANF schedule.
2. Identify whether the business is card-present, card-not-present or mixed.
3. Count active CP locations and merchant IDs.
4. Establish historical monthly Visa CNP volume.
5. Review the old processor’s pricing schedule.
6. Review the new processor’s pricing schedule.
7. Identify all fixed monthly network, processor, gateway and software charges.
8. Model a mid-month switch.
9. Model a month-boundary switch.
10. Decide whether potential cost reduction justifies waiting.

Before signing the new agreement

11. Get FANF pass-through treatment in writing.
12. Confirm whether FANF is separately itemized.
13. Confirm whether the processor adds markup.
14. Confirm how CP locations are counted.
15. Confirm how CNP tiers are determined.
16. Ask how the first partial month is treated.
17. Document monthly minimums and recurring fees.
18. Confirm token and recurring credential migration.

Before turning off the old processor

19. Confirm the last new-sale date.
20. Confirm the new processor is production-ready.
21. Test live transactions.
22. Export old statements and transaction records.
23. Confirm the legacy refund path.
24. Confirm chargeback/dispute access.
25. Obtain the formal account-closure procedure.
26. Get residual billing expectations in writing.

During cutover

27. Stop routing new sales to Processor A.
28. Start new sales on Processor B.
29. Verify authorization and settlement.
30. Verify reports and funding.
31. Restrict legacy terminals and gateways from accepting accidental new sales where supported.
32. Preserve only required legacy refund, dispute and reporting functions.

After cutover

33. Review the final old-processor statement.
34. Review subsequent residual statements rather than ignoring them.
35. Categorize each old-account charge.
36. Audit the first new statement.
37. Verify the CP location count.
38. Verify the CNP Visa volume and tier.
39. Compare processor markup with the signed proposal.
40. Challenge unexplained differences in writing.

Frequently Asked Questions

Conclusion

A processor migration can produce two FANF-related charges in one transition month because the old and new acquirer relationships are separate. When both handle Visa activity, each relationship may produce its own network-fee billing depending on the merchant’s configuration and the rules applicable to that activity.

The correct response is not to assume either that the charges are wrong or that they are automatically valid. Card-present and card-not-present activity should be analyzed separately. CP merchants need to verify location and merchant-account configuration, while CNP merchants need to reconcile Visa volume and the tier treatment used by each processor.

A clean month-boundary cutover can reduce overlap and simplify reconciliation, but operational stability comes first. Merchants also need a controlled legacy path for refunds, disputes, reporting and historical transaction research.

Finally, do not stop the audit when Processor A closes. Review the old final and trailing statements, then scrutinize Processor B’s first bill for FANF treatment, location count or CNP tier, fixed fees and processor markup. That final reconciliation is what separates a well-controlled processor migration from one in which payment costs remain unexplained.