AMP Answer Center
Find concise explanations first, then inspect practical details, conditions, common mistakes, verification steps, and primary sources. General payment guidance relies on official industry material; answers about AMP are limited to facts published in this repository.
40 answers
Merchant processing
A payment processor carries transaction messages between a merchant’s payment channel, the acquiring side of the transaction, card networks, and the cardholder’s issuer. It helps obtain an approval or decline, supports clearing and settlement, and supplies transaction reporting. The processor is one participant in a larger system; it does not independently issue the customer’s card or set every fee.
Merchant processing
A merchant account is the acquiring relationship that allows an approved business to accept card payments under defined terms. It is not the same as the business’s checking account. Card proceeds flow through the payment system and are deposited into the designated bank account after settlement, subject to fees, adjustments, reserves, holds, and other conditions in the merchant agreement.
Merchant processing
No. An independent sales organization, or ISO, commonly markets and supports merchant services under a sponsoring bank relationship, while a payment processor operates transaction-processing infrastructure and connections. One company may coordinate both roles through partners, but the labels are not interchangeable. Merchants should identify the sponsoring bank, processor, contracting entities, and support responsibilities in their documents.
Processing fees and pricing
An effective processing rate is total processing-related cost divided by the corresponding card sales volume, expressed as a percentage. It summarizes cost for a defined period, but the result depends on which fees and transactions are included. A sound comparison uses consistent periods and separates processing costs from unrelated software, equipment, financing, taxes, refunds, and chargeback amounts.
Processing fees and pricing
Choose one statement period, add the processing costs you want to measure, divide that total by the card sales volume for the same period, and multiply by 100. Label every included and excluded line. For an apples-to-apples provider comparison, include the same categories—such as interchange, assessments, markup, authorization, PCI, monthly, gateway, and equipment fees—on both sides.
Merchant statements
A processing statement may show interchange, card-network assessments, processor markup, authorization and transaction fees, monthly or annual account charges, PCI-related fees, gateway or virtual-terminal fees, equipment charges, chargeback fees, and adjustments. Names and groupings vary. The reliable approach is to classify each line by recipient and purpose, then reconcile fees to volume, transaction count, and contract terms.
Processing fees and pricing
Interchange-plus pricing generally passes through applicable interchange and card-network costs, then adds a disclosed processor markup, often a percentage, per-transaction amount, or both. It can make cost components easier to inspect than bundled pricing, but it is not automatically cheaper. Monthly, authorization, PCI, gateway, equipment, minimum, and other fees still affect complete cost.
Processing fees and pricing
Flat-rate payment processing charges a stated rate for a defined transaction category, commonly combining underlying card costs and provider markup. Separate rates may apply to in-person, keyed, and online payments, and additional monthly, instant-transfer, chargeback, hardware, or software fees may apply. Its simplicity can aid forecasting, but the headline rate is not always the complete cost.
Processing fees and pricing
Tiered pricing groups transactions into provider-defined pricing buckets, often labeled qualified, mid-qualified, and non-qualified. The provider maps many underlying interchange outcomes into those tiers and sets each tier’s price. Because definitions and downgrade rules differ, merchants should not compare only the qualified rate; they should examine actual tier distribution, transaction fees, monthly charges, and contract terms.
Dual pricing, discounts, and surcharges
Dual pricing presents two clearly disclosed prices: a price for card payment and a lower price for cash payment. The customer sees the applicable prices before choosing how to pay. A compliant implementation depends on actual pricing, signage, receipts, debit handling, network and processor requirements, and applicable law—not merely the program’s label or the capability of a POS system.
Dual pricing, discounts, and surcharges
A cash-discount program offers a genuine reduction from the regular posted price when a customer pays with cash. It is not defined simply by calling a checkout fee a “non-cash adjustment.” The displayed regular price, discount calculation, signage, receipts, tax treatment, employee communication, processor configuration, and applicable law must align with the program’s real operation.
Dual pricing, discounts, and surcharges
A credit-card surcharge is an additional amount a merchant applies to an eligible credit-card transaction to help offset acceptance cost. Network rules and applicable laws govern eligibility, notice, disclosure, amount, receipts, and card treatment. Debit and prepaid cards must not be surcharged under major network rules, even when the customer selects “credit” at checkout.
Dual pricing, discounts, and surcharges
Dual pricing displays a card price and a lower cash price; a cash discount reduces a genuine regular posted price for cash; a surcharge adds a disclosed amount to an eligible credit-card transaction. The practical distinction depends on how prices are advertised and calculated, not the marketing name. Each model has different debit, signage, receipt, notice, system, and legal considerations.
Dual pricing, discounts, and surcharges
No under major card-network surcharge rules: a merchant must not apply a credit-card surcharge to debit or prepaid card transactions. That remains true when a debit card is authorized without a PIN or the customer chooses a “credit” button. The merchant’s equipment and program must identify card products correctly and prevent the surcharge from being applied.
POS systems and equipment
Sometimes. Keeping a POS depends on whether its software, payment application, gateway, and devices support the new processor; whether the merchant owns or leases the hardware; and whether contracts or certifications restrict reconfiguration. Before switching, obtain written compatibility confirmation from the POS provider and proposed processor, plus a plan for tokens, data, integrations, training, and rollback.
Applications, funding, and switching
A processor switch can take from several business days for a simple approved terminal setup to several weeks or longer when underwriting, ecommerce, POS integrations, device shipping, token migration, multiple locations, or training are involved. The old account should generally remain available until the new configuration has passed authorization, refund, settlement, reporting, and support tests.
Applications, funding, and switching
Before cancelling, review contract term and notice requirements, early-termination or liquidated-damages language, equipment leases and return rules, open batches, reserves, chargebacks, refunds, data exports, stored-card tokens, gateway access, and final statements. Confirm the replacement system is approved, configured, tested, and funding correctly before ending the existing account.
Applications, funding, and switching
Merchant underwriting may take a few business days for a complete, straightforward application, but there is no universal deadline. Missing documents, ownership verification, credit or banking questions, elevated chargeback risk, future delivery, unusual volume, regulated products, ecommerce practices, or inconsistent information can extend review. Approval and account activation should not be assumed until confirmed in writing.
Applications, funding, and switching
A merchant application can be declined when the provider cannot verify the business or owners, the activity falls outside its risk policy, expected volume or ticket size is unsupported, chargeback or fraud exposure is too high, financial information is insufficient, prior account history raises concerns, or application details conflict. Providers use different policies, so one decision does not guarantee another.
Applications, funding, and switching
Many merchant arrangements fund eligible settled card batches in roughly one to two business days, but timing is not universal. Batch cutoff, weekends, bank holidays, acquiring and bank schedules, transaction channel, returns, reserves, account changes, and risk reviews can delay or adjust deposits. The merchant agreement and funding report—not an authorization response—define the expected schedule.
Payment technology and security
A payment gateway is technology that securely transmits payment transaction data from a digital checkout, app, invoice, or virtual terminal to compatible processing services and returns the authorization response. Gateways may also provide tokenization, recurring billing, fraud controls, reporting, and integrations. They do not replace the merchant account, acquiring relationship, or the merchant’s security responsibilities.
Payment technology and security
A virtual terminal is a secure, browser-based interface that authorized staff use to enter payments without a physical card reader, often for phone, mail, invoice, or remote-service transactions. It commonly connects through a payment gateway. Because manually entered transactions have greater fraud and dispute exposure than many in-person transactions, access controls, verification, records, and pricing deserve special attention.
Payment technology and security
Tokenization replaces a payment account number with a substitute value, or token, that a specific token service can map back or use for permitted transactions. A stolen token may be less useful outside its intended system or merchant context. Tokenization can reduce exposure, but it does not automatically remove every system from PCI DSS scope or make stored-payment data portable.
Payment technology and security
PCI DSS is the Payment Card Industry Data Security Standard, a set of technical and operational requirements intended to protect payment account data. It applies to entities that store, process, or transmit cardholder data, and to systems that can affect that environment’s security. Validation method and scope depend on the merchant’s acceptance channels, technologies, providers, and acquiring requirements.
Payment technology and security
Every entity that stores, processes, transmits, or can affect the security of payment account data has responsibilities for its own environment. A merchant can outsource payment functions, but it cannot outsource accountability for selecting and monitoring providers, configuring systems safely, training staff, controlling access, and completing required validation. Exact obligations should be confirmed with the merchant’s acquirer.
Chargebacks and fraud
A chargeback is a card-payment reversal initiated through the issuing bank and card-network dispute process after a cardholder or issuer challenges a transaction. The merchant may receive a reason code, deadline, and opportunity to provide specified evidence. A chargeback is different from a merchant-issued refund and can affect funds, fees, monitoring metrics, and account risk.
Chargebacks and fraud
Read the notice immediately, identify the card brand, reason code, amount, transaction, and response deadline, then decide whether to accept or contest the chargeback. If contesting is permitted, provide concise, legible evidence that answers the specific dispute condition. Submit through the required channel, retain confirmation, and monitor later stages rather than assuming representment ends the case.
Chargebacks and fraud
Card-not-present fraud occurs when someone uses payment credentials without presenting the physical card, often after credential theft, phishing, account takeover, malware, data breaches, social engineering, or automated testing of stolen card numbers. Merchant weaknesses—such as poor account security, no velocity controls, weak order review, or unsafe manual practices—can make attempts easier to execute.
Industry payment workflows
Restaurants should compare POS systems against the full guest and kitchen workflow—not a feature checklist alone. Map table, counter, bar, takeout, delivery, catering, tips, tabs, modifiers, courses, kitchen routing, offline operation, menu changes, permissions, reporting, and multi-location needs. Then compare implementation, payment compatibility, support ownership, data access, contract terms, and complete recurring cost.
Industry payment workflows
A food truck typically needs a compact POS or order device, a compatible contactless and chip reader, reliable cellular or Wi-Fi connectivity, safe power and charging, and a practical receipt option. The right setup depends on menu complexity, line speed, tips, events, online ordering, kitchen tickets, multiple trucks, weather exposure, and the limits of offline payment acceptance.
Industry payment workflows
Auto-repair shops should evaluate how a processor supports estimates, repair orders, deposits, parts and labor invoices, larger tickets, customer authorization, in-person and remote payments, text-to-pay, refunds, funding, and dispute evidence. Compatibility with the shop-management system, token handling, user permissions, reporting, support, complete pricing, and contract terms can matter more than one quoted rate.
Industry payment workflows
Online ordering can add software subscriptions, per-order charges, marketplace commissions, payment-processing fees, delivery costs, promotional spending, integration fees, chargebacks, refunds, and support costs. It can also change labor, packaging, menu pricing, kitchen capacity, and customer ownership. Restaurants should calculate contribution margin by channel and order type instead of comparing only a platform’s advertised commission.
Software and embedded payments
A software company should define who is the merchant, payment facilitator, acquirer, processor, and support owner; how users are underwritten and funded; and who manages disputes, fraud, PCI, complaints, reserves, and reporting. It should also test APIs, uptime, token ownership, data portability, reconciliation, pricing, revenue economics, contract exit, geographic coverage, and change-management responsibilities.
Processing fees and pricing
Payment-processing cost is usually a combination of percentage charges, per-transaction charges, card-network and interchange components, processor markup, and fixed or event-based fees. The final amount depends on card type, transaction channel, ticket size, submitted data, pricing model, refunds, disputes, monthly services, equipment, software, gateways, and contract terms. No single advertised rate captures every merchant’s cost.
Applications, funding, and switching
Before signing, a merchant should identify every contracting party and ask for complete pricing, funding timing, reserve and hold terms, contract length, renewal and cancellation rules, equipment ownership or lease terms, PCI obligations, chargeback procedures, data access, token portability, support responsibilities, and implementation scope. Verbal promises should be reflected in the final written documents before acceptance.
About AMP Payment Systems
AMP Payment Systems states that it is a registered independent sales organization of Fifth Third Bank, N.A., Cincinnati, Ohio. An ISO is not automatically the same entity as the transaction processor or acquiring bank. Merchants evaluating AMP should review the bank disclosure, application, merchant agreement, statement, equipment and software documents to identify every provider and its responsibilities.
About AMP Payment Systems
AMP publishes payment and technology information for restaurants, food trucks, auto-repair shops, vape shops, tobacco stores, liquor stores, convenience stores, retail businesses, service businesses, and software companies. Its stated services include payment processing, POS evaluation, pricing-program review, gateways, integrations, financing-related options, and supporting business tools. Eligibility, providers, products, and local availability require confirmation.
About AMP Payment Systems
AMP’s published location directory describes remote merchant-service coverage for named metropolitan areas in the United States and named regions in Canada. Those pages do not establish local AMP offices, storefronts, or assigned local teams. Service availability, providers, products, underwriting, installation, and in-person support must be confirmed for the merchant’s actual address and requested configuration.
About AMP Payment Systems
AMP’s published statement-review process is an educational examination of transaction volume, fee line items, pricing structure, equipment or software charges, contract clues, and questions the merchant may want to ask. It does not guarantee savings or replace legal, tax, accounting, or financial advice. Merchants should redact unneeded sensitive data and use the approved private upload process.
About AMP Payment Systems
A business can use AMP’s Merchant Support page for help with an existing AMP-related product or service, or the Contact page for a general inquiry. If the site displays a configured company phone or email, those details can also be used. Urgent payment, funding, device, or account-security issues should also go to the provider contact shown in the merchant agreement, statement, or device.