Retail Authorization Fee Review: Requests and Billing

Start with the retail store’s actual collection records

A basket can contain several products while producing a different number of payment requests. Split tender, an uncertain result or a separate online route needs its own supported explanation. Do not use the number of scanned items as an authorization count or treat an inventory adjustment as a payment event.

For an online order collected by the store, connect the basket reference to the provider record and applicable gateway invoice. A collection confirmed successful with an open basket is a posting issue to investigate before another charge. Keep the fee review separate from the decision about stock and fulfilment.

Connect the basket, stock movement and payment

Choose one product and follow it from receiving through a sale and return. Confirm the unit of sale, barcode, variant and stock location. A case, individual unit and colour variant should not be treated as interchangeable simply because their names are similar. Use representative products from the store rather than accepting a demonstration built around one generic item.

Identify which application owns available stock. A website connector might synchronise orders without maintaining every inventory field. Confirm the supported product identifiers, update timing and failure notifications. Demonstrate the last available unit being sold through the relevant channels and record what prevents another employee or website buyer from purchasing unavailable stock.

Keep the sale and payment references connected. A standalone terminal may collect a correct amount while requiring a separate sales entry; an integrated POS may perform that handoff automatically only under a particular configuration. Test what happens when payment succeeds but the basket does not close. Check status before retrying so a display or posting problem does not create a duplicate charge.

Returns need their own stock decision. A damaged product may be refunded without becoming available for resale. An online purchase returned in store may require a different payment and inventory workflow. Confirm those steps with the responsible providers and the store’s own return policy, including employee permissions and the evidence retained for overrides.

For closeout, compare product sales, discounts, returns and tenders with processor settlement. A stock report is not proof of a bank deposit, and a processor total is not an inventory ledger. Save the date range and location filters with the reconciliation packet. Your bookkeeper should approve accounting and tax mappings rather than relying on default categories.

Define the event the provider is billing

An authorization fee needs a defined event before its count can be reviewed. Ask whether the agreement bills an authorization request, an approved request, a settled transaction or another specified action. Do not infer the answer from a short statement abbreviation. Obtain the applicable schedule and the provider’s explanation for the account and period under review.

Keep authorization, capture, settlement and transfer status distinct. A request seeking a payment decision is not the same record as a bank deposit. A fee can relate to an event even when the business does not see a completed sale, depending on the actual terms. That possibility needs confirmation, not an assumption that every extra request is an error.

Write the definition beside the statement line. Record the eligible channel, unit rate, count, rounding method and any exclusions. If the provider cannot identify the basis, keep the charge marked unresolved while requesting the supporting detail.

Use a request count instead of substituting sales volume

A per-request amount is tested with an eligible count multiplied by its agreed unit price. Card sales volume answers a different question. An effective percentage can help summarise complete cost, but it does not establish how many events were billed or whether the line follows the written calculation.

For a fictional schedule charging $0.04 for each eligible request, 1,250 eligible requests produce $50.00. The arithmetic does not prove that the real account has that rate or that every request in a dashboard is eligible. First match the channel, date range and event definition, then reproduce the calculation.

If the statement contains several request categories, calculate each separately before combining them. Preserve the original counts and prices. A single blended average can hide a changed mix or an omitted category, especially when remote and in-person collection follow different routes.

Investigate the difference between requests and completed sales

Build a comparison using the same account, reporting period and timezone. List completed sales separately from the provider’s billable request count. Ask which documented events explain the difference: unsuccessful attempts, supported adjustments, verification activity or another account-defined action. Do not label every difference a duplicate charge.

Select a small non-sensitive sample with a business reference, time and provider reference. Ask the responsible provider to trace the request history and billing treatment. Repeated attempts after an uncertain result deserve an operational review as well as a fee review, because the underlying issue may be staff retry behaviour or an application handoff.

Keep customer collection status separate from the cost question. Resolve an uncertain payment through the provider’s supported procedure before collecting again. A desire to investigate request charges is not a reason to perform additional live attempts or change a successful payment record.

Separate authorization charges from gateway and related services

The same payment route may involve more than one service. Identify which entity bills processing, gateway usage and any other enabled feature. A provider example can show distinct fee fields without establishing that every merchant owes every line. Use your actual invoices and agreement to determine what applies.

Create one row per charge with its issuer, description, count or amount basis and billing period. Check whether a dashboard subtotal already includes an item shown elsewhere in detail. Counting both can overstate cost. Conversely, reviewing only a processor statement can omit a separately billed gateway service.

Ask for a written explanation when two lines appear to use similar events. Separate services are not automatically duplicate billing, but similar names are not sufficient evidence that both calculations are correct. Retain the response and compare it with the accepted schedule.

Review low-ticket and high-frequency activity consistently

A fixed charge matters differently when average tickets differ. Use fictional figures to understand the effect: a $0.04 event fee is 0.4% of a $10 sale and 0.04% of a $100 sale. These percentages describe that single illustrative fee only. They are not complete processing rates or a forecast of the merchant’s bill.

Model the business’s actual event count and ticket distribution instead of multiplying a quoted percentage by one convenient month. Keep collection routes and separately billed services visible. The useful comparison is a complete cost model under consistent assumptions, with unsupported items left open for confirmation.

Do not remove a legitimate customer option or combine unrelated sales just to make one line look smaller. Any workflow change must preserve accurate customer amounts, supported collection procedures and business records. The operating effect can be more consequential than the visible event fee.

Check first, partial and changing billing periods

Record the activation date, statement boundaries and any dated pricing amendment. A first statement can cover a period that does not match the business’s normal reporting month. Ask the provider how rates and counts are allocated when a change occurs within that period.

Compare request-detail dates with the statement’s documented recognition basis. Avoid moving an event into a different month solely because the bank transfer appeared later. Keep the original report filters so another reviewer can reproduce the result without guessing which timezone or channel was selected.

Where the provider issues an adjustment, retain its reference and the later statement entry. A support promise is not the same as a posted credit. Close the question only after the explanation and resulting billing treatment can be connected to the affected period.

Prepare a focused billing question

State the account identifier through the provider’s approved route, the statement period, the exact line and your calculation. For example, explain that the displayed count multiplied by the agreed rate produces one amount while the billed line shows another. Ask which count, rounding rule or schedule provision explains the difference.

Avoid sending full card numbers, security codes, customer bank documents or login credentials. A non-sensitive request reference is usually a better starting point; the verified support team can identify any additional approved evidence it needs. Keep the question specific enough that it can receive a factual answer.

Record the case owner, expected next action and the answer received. Distinguish a clarified calculation from a confirmed correction or a commercial request to change future pricing. Those are different outcomes and should remain visible in the review notes.

Evaluate a proposed rate change against the complete setup

Ask whether the quoted request price is included, separate or conditional under the new proposal. Confirm its event definition and eligible channels. A lower unit price with a broader billable count may not produce the same result as a straightforward reduction on the existing basis.

Include software, gateway, equipment, periodic and implementation costs in the comparison. Keep one-time costs separate from recurring costs and compare realistic quiet and busy periods. Retain uncertainties instead of replacing missing information with zero. No public example establishes the price available to an individual business.

Before switching or changing configuration, confirm the supported operational handoffs, correction routes and account obligations. Have the relevant business owner accept the full proposal. A request-fee review can support that decision without proving savings, approval or suitability of a particular provider.

Use a controlled review worksheet

Keep the original line wording, supporting rate, eligible count, calculated amount and billed amount together. Add the report source, period, filters and provider explanation. Include an explicit unresolved status when the event definition or evidence is missing; a blank cell should not imply that the charge is zero.

Have a second authorised reviewer reproduce a representative calculation. They should be able to explain why the selected count is appropriate and why other counts were excluded. If they cannot, improve the definitions before drawing a conclusion about the full statement.

After resolution, preserve the worksheet and any dated change to the agreement. Use the same method next period while checking whether the channel mix or configuration changed. Consistency makes the review useful without turning one month’s arithmetic into a guarantee about later billing.

Who should approve the review?

Have the store manager confirm the operational references and the financial owner confirm the statement calculation. Ask the provider to explain the applicable terms. Keep unresolved items and any accepted commercial change separate, with a named owner and an effective date. Use a non-sensitive summary for an initial enquiry rather than attaching customer or bank records.

Prepare the review without exposing private records

Summarise the business, current software, payment channels, locations and the specific sale problem you want resolved. Include a non-sensitive example and the outcome you expected. That gives a review more direction than a general request for better rates or a new device. List existing components you want to retain so proposals account for them.

Process Rite helps organise the payment requirements, provider questions and written comparison. Availability, integration, account approval, implementation and service terms need confirmation in the applicable proposal and provider agreement. Hardware, software, applications and processing charges should remain identifiable. Request a custom proposal based on the configuration and channels your business actually needs.

Use the website enquiry for the summary, then arrange document sharing after contact. Do not submit payment credentials, bank logins, passwords or private customer records. Include your town and preferred callback time so the conversation starts with the right context. Consultations and any site work are arranged directly. Confirm the responsible support contact and available service hours in the proposal.

Sources and review scope

Documentation reviewed October 17, 2026. Provider documentation supports product-specific facts; it does not confirm another provider’s terms or the suitability of an individual configuration. These operating examples are proposed checks, not reports of hands-on product testing. Worked amounts and records are fictional.

PAYARC: example provider change form showing separately identified fee fields

Clover^®: overview of merchant services and pricing models

Related guides for your business

Retail POS and inventory guide

Retail checkout improvement

Retail online and in-store payments

Retail reporting and reconciliation

Retail batch fee review

Retail monthly minimum fee review

Retail qualified and nonqualified pricing

Keep an acceptance checklist

• The billed event and eligible request types are defined.
• The statement count and unit rate reconcile to supported detail.
• Separate gateway and processing charges are identified without double counting.
• A proposed change preserves supported payment handling.

Discuss the configuration you actually need

Tell Process Rite your business type, town, current software and the specific question to review. Start with a non-sensitive summary and arrange document sharing after contact. Do not submit payment credentials, bank logins or private customer records.

Equipment, software, applications and implementation are separately quoted. Availability, integration, approval, pricing and service terms need confirmation in the applicable proposal and provider agreement. A review does not guarantee savings, approval, legal compliance or a dispute outcome.

Request a free payments review · Review the complete cost · Find the right support route