Payment Gateway, Processor and Merchant Account: Who Does What?

Learn how gateways, processors, merchant accounts and banks work together. Map the contracts, payment records and support owners behind a card sale.

Roots Payments
Published
Updated
Timestamps use America/Chicago. Date-only records have no recorded time.
Shop owner reviewing three blank role cards on a wooden counter beside an unbranded payment terminal.

A payment gateway connects your checkout to payment processing. A processor handles transaction messages. A merchant account is the acquiring relationship that lets your business accept card payments. Buying gateway access alone does not establish a merchant account or determine your eligibility and funding terms.

Identify who supplies each function, which agreement covers it and who answers when something fails. One provider may bundle several functions; an independent arrangement may use separate companies. In either case, a checkout approval and a deposit in your business bank account are different events.

What the gateway does—and what it does not establish

The gateway connects your website, application or terminal to the processing system. Authorize.net describes its gateway as passing transaction information to a processor and returning the result to the merchant. It carries payment instructions and responses; gateway access alone does not establish approval for card acceptance.

Gateway products can include other tools. NMI’s gateway page lists transaction reporting, recurring billing and connections to multiple processors. It also says available currencies depend on the processor. Ask the provider to confirm support for your account, currency and checkout configuration before relying on an advertised connection.

Keep two questions separate: “Can this software send the payment?” and “Is my business approved to accept it through this arrangement?” The first needs a supported integration and confirmed configuration. The second needs account approval and an acquiring or payment-service agreement. A gateway login answers neither question on its own.

Processor, acquirer, issuer and network are different roles

The processor handles transaction processing. In the Authorize.net example, it receives the gateway request, passes it onward through the card system and returns the response. The issuer is the financial institution that issued the customer’s card. It serves the customer’s card account.

The acquirer supplies card acceptance services to the merchant. Mastercard identifies acquirers as financial institutions providing those services. Its explanation also separates interchange from the merchant’s total price: interchange is one component of the merchant discount rate set by the acquirer. A gateway invoice or a network interchange schedule cannot substitute for your complete processing fee schedule.

The card network connects the issuing and acquiring sides. Mastercard’s switching explanation distinguishes authorization messages, clearing information and settlement of funds between issuers and acquirers. This role is separate from your gateway, sales representative and business bank.

A provider may use “processor” to describe the whole service. When mapping responsibilities, use the legal names on the agreement and statement. Ask which entity provides acquiring, which handles technical processing and which is your first support contact. Those answers can differ even when the invoice carries one brand.

A merchant account is not your everyday business bank account

The merchant-account relationship supports card acceptance and settlement; your business bank account is the destination where you receive payouts and manage operating cash. Authorize.net’s plan explanation explicitly distinguishes the two. Do not assume that opening an ordinary business bank account also sets up card acceptance.

Authorize.net’s payment documentation assigns merchant underwriting to the acquiring bank. Before launch, obtain your business’s approval and terms. Check the legal entity, permitted activity and payment channels, along with funding terms, any reserves and account restrictions. If a term is missing, ask the provider; another merchant’s experience does not establish yours.

For funding, ask who can explain a payout, who can change the destination bank details and who handles a held or missing payment. Record the escalation route as well as the advertised support number. Your receiving bank can help investigate an incoming transfer. Ask the payment provider whether it sent the payout and which transfer reference is available. Reference availability and escalation procedures depend on the provider and banking arrangement.

What changes when services are bundled?

Authorize.net’s Gateway only plan connects an existing merchant account, while its All-in-one plan includes a merchant account and gateway, subject to eligibility. Its pricing page also says the merchant account can have separate terms. These descriptions apply to Authorize.net’s plans; other bundles may work differently.

With a separate gateway, confirm compatibility with the processing arrangement before buying or replacing anything. With a bundle, ask the provider to identify the underlying responsibilities even if it offers one signup or support channel. Bundling changes how you buy and manage the service; it does not remove the need to understand acquiring approval, charges and funding conditions.

For either approach, ask what the agreement includes, what is billed separately and what happens if you change gateway, processing provider or business bank account. Confirm migration requirements in writing before assuming that keeping a website or login will preserve its payment connections.

Map a sale from checkout to the bank

Follow a $100 USD online card order through a separate gateway and an approved acquiring arrangement. No fee, payout amount or arrival date is assumed. The steps separate transaction messages from funding. The merchant-account relationship supports processing throughout; it is not another stop for the payment message.

Follow the payment instructions, then the funds

A $100 USD order under the stated assumptions. Authorization, capture and payout are separate stages; the approval does not establish a deposit date or net payout.

  1. Checkout creates the request

    The merchant’s checkout records the $100 order and submits the payment request through its configured gateway connection. Keep the order reference so it can be matched to the payment record.

  2. Gateway passes it to processing

    The gateway sends the transaction information to the configured processor. Confirm which processing connection and merchant account this checkout uses; a gateway brand alone does not identify them.

  3. Processor, network and issuer return a decision

    The request reaches the card’s issuer through the processing and network arrangement. The response returns to the checkout. A decline or error needs its actual response record; an approval is not evidence of a bank deposit.

  4. Capture submits the approved payment for settlement

    Authorization and capture can be combined or separate. In Authorize.net’s documentation, authorization holds an amount without transferring funds, while capture queues it for settlement. Check your actual configuration and transaction status.

  5. Acquiring arrangement handles settlement and payout

    Clearing and settlement connect the issuing and acquiring sides. Check the provider’s funding report and agreed terms for the payout to the business bank account. Do not infer the net amount or timing from the $100 approval.

  6. Trace a missing deposit

    If a captured payment has no payout reference, ask the payment provider’s funding support for its status. Keep funding unresolved until the records explain it. Once a transfer reference exists, use it with the receiving bank if needed.

Match order reference → gateway transaction reference → capture or batch record → payout reference → bank entry. Keep the status shown at each stage. Record “authorized” as authorized, and leave a missing record unresolved until the responsible provider supplies it.

Build a responsibility table before you commit

Copy the table and fill in the legal entities from your agreements and statements. Add a separate support contact if the contracting party delegates day-to-day service. If one company fills several roles, repeat its name so each responsibility and supporting record stays clear.

Who handles each part of a card payment?
FunctionContracted entityEvidenceFinancial roleQuestion owner
Checkout and order recordYour commerce platform or software supplierOrder export and integration configurationCreates the order and payment request; does not prove receipt of fundsMerchant operations and integration support: Which order matches this payment?
GatewayGateway supplier named in your agreementGateway agreement, connection details and transaction reportTransmits payment instructions and responsesGateway support: Which processor connection received the request?
Processing arrangementProcessing provider identified by your service providerProcessing setup record, statement and response detailsHandles transaction messages and processing recordsProcessing support: What status and response were returned?
Merchant account / acquiringAcquirer and merchant-service contracting parties; confirm legal namesApproval, merchant agreement and complete fee/funding termsProvides the acquiring relationship for card acceptanceAccount provider: Is this activity approved, and which terms govern it?
Card issuer and networkCustomer’s issuer and relevant card network; separate from your supplier contractsCard/network information and transaction response available in provider recordsIssuer-side decision and network connection between issuer and acquirerPayment support routes merchant questions; customer contacts issuer for card-account questions
Payout and receiving bankFunding provider plus your business bankFunding report, transfer reference and matching bank entryProvider sends payout; business bank receives itFunding support first; receiving bank with transfer reference if needed
Unresolved payout termsNot yet identifiedCurrent funding schedule or agreement section still neededNet amount and arrival date remain unconfirmedAsk the account provider to identify funding owner and written terms before relying on them

Ask gateway support about the connection, the account provider about acceptance and terms, and funding support about payouts. Match each answer to the relevant record. Missing payout terms remain unresolved until the account provider supplies them.

If you already have an approved processing arrangement, start with the independent gateway overview and bring the connection details. If you need to establish card acceptance, start with the merchant account overview. Ask Roots to clarify the proposed service scope and provider responsibilities. Approval, pricing and funding terms come from the actual provider agreements.

Related products and services

Related reading

Authorization, Capture and Settlement: What Each Means for a Merchant

Authorization, capture, clearing, settlement and payout explained for merchants. Learn which records confirm each stage and how to trace a missing bank deposit.

What Makes Up a Merchant’s Total Payment Acceptance Cost?

See what accepting payments costs beyond the quoted rate. Use your statements and invoices to calculate processing charges, equipment, software and staff time.