How do payments work inside Salesforce?Gateways, card versus ACH, payment profiles, PCI scope and dunning

Payments, in a B2B revenue system, are the step where an invoice or order becomes money: a payment gateway encrypts and transmits the card or bank details and returns approved or declined, a processor moves the funds and settles them to your bank, and the billing system records the result against the invoice it paid — applying the amount, updating the balance, and storing a status a report or a workflow can act on. The gateway decides how the money moves. The billing system decides what to charge, when, and whether it landed.

Gateway, processor, billing system: who does what

The three terms get used interchangeably, and the confusion costs money because it hides where the important decisions live. The gateway guide draws the lines in detail.

The practical consequence: a tenth of a percent on the card rate is noise next to a recurring charge that never adjusted for a one-time payment, or a declined card nobody in the CRM saw for three weeks. Choose the gateway by payment method and region. Judge the billing system by what it does with the result.

The four gateways on their published fees

Stripe, Authorize.Net, PayPal and eWay are the gateways most Salesforce billing systems connect to. All four tokenize stored payment methods, support recurring charges and provide a sandbox. They differ on fees, ACH, region and wallets. Every figure below is from the vendor's own pricing page as of September 2026, and each is linked in the sources; fees change, and the page is the source of truth. Volume and custom pricing exist and are not listed.

Card rates cluster within a few tenths of a percent of each other. The real differences are the monthly fee, whether ACH is available, wallet coverage (Apple Pay and Google Pay are named by Authorize.Net, PayPal and eWay), and multi-currency handling — eWay states that multi-currency requires a separate account per currency. If you run more than one gateway, the billing system has to route each payment to a processor by currency, region, payment method or the customer's saved default, and refunds have to go back through the processor that took the original payment.

Card versus ACH: the B2B arithmetic

Consumer subscriptions run on cards. B2B subscriptions run on cards for small amounts and on ACH, wire or check for large ones, because that is how accounts payable departments pay and because the fees are different in kind. Card fees are a percentage of the invoice with no ceiling. ACH fees at Stripe and PayPal are a lower percentage with a per-transaction cap; Authorize.Net's eCheck is a lower percentage as published. Work it on one invoice.

On the annual invoice, the difference between card and capped ACH is more than a thousand dollars per payment. Across a customer base that pays annually, the choice of rail is the largest cost line in this guide, and it is invisible in a gateway comparison that only lists card rates. Two cautions. ACH is not instant: a bank debit can be returned days after it appeared to succeed — wrong account number, closed account, insufficient funds, a dispute — so treat an ACH payment as final only after the return window has passed; Nacha publishes the rules. And ACH has to be processed, not just recorded: the test of a billing system is whether a bank debit runs through the gateway with a status written back, or whether "ACH" means a manual payment someone types in when the bank statement arrives.

Wire and check remain. No gateway handles them; the billing system records them as manual payments against the invoice with the reference or check number, and they should show in the same payment list and the same account balance as everything else.

Stored payment profiles and recurring charges

A stored payment profile is a saved payment method — a tokenized card, a PayPal recurring agreement, or a bank account for ACH — tied to a contact or account so future invoices can be charged without re-entering details. The customer enters the card once. The gateway stores it and returns a token. The billing system stores the token, the card type and the last four digits, and nothing else. Every later charge uses the token.

Profiles are what two things run on. One-click invoice payment: the customer, or an internal user, pays an invoice against the saved default. And recurring charges: a standing instruction to charge the stored method on a schedule — a start date, a frequency by day, week, month or year, and a number of occurrences — with the next payment date visible on the record and controls to cancel, suspend, update or bill an outstanding amount. Some gateways run the schedule on their side; some billing systems run it and call the gateway each cycle. Either works if the result is written back to the invoice.

One rule about recurring charges that catches teams out: a recurring charge is independent of any ad-hoc payment. If a customer with an active recurring charge makes a separate one-time payment, the schedule does not know, and the standing instruction has to be cancelled and re-created against the updated balance. Ask any billing vendor how they handle that case before you rely on recurring charges for B2B invoices.

PCI scope: what touches card data and what does not

PCI DSS, the card industry's data security standard maintained by the PCI Security Standards Council, applies to every system that stores, processes or transmits cardholder data. The design goal for a CRM-side billing system is to keep as much of that scope as possible on the gateway's side of the line.

Whatever the architecture, the questions to ask a vendor are the same: where does the card number go when a user types it, what is written to the payment record, what is written to debug logs, and can the vendor show you the payment record with the full number absent. A billing system that stores the last four digits and the card type is storing what the customer needs to recognize the charge and nothing a thief could use.

Payment terms, applied payments and the account balance

B2B invoices are paid on terms — Net 30 by default, longer on enterprise deals — so the billing system has to know the due date, show how many days an invoice is past it, and keep an account balance that rolls up every open invoice. Applied payments are the mechanism: one payment often covers several invoices, and one invoice is sometimes paid in two parts, so the system applies amounts, shows applied and balance-due per invoice, and rolls the open balance to the account. That roll-up is what an account owner needs before selling into an account that is past due, and it is what a credit hold runs on. Refunds and voids go back through the original payment; credits and adjustments live as lines against the invoice rather than edits to it. The quote-to-cash and billing guide covers the invoice side, including the boundary with the ERP.

Dunning and involuntary churn

Involuntary churn is a customer lost because a payment failed, not because they decided to leave. In B2B it includes invoices that went unpaid because they never reached accounts payable, lacked a PO number, carried a disputed line, or simply aged past terms with no failure event at all. It is the cheapest churn to fix because there is nothing to persuade; there is a working payment method to obtain and a person who notices in time. The involuntary churn guide covers the causes and the workflow; the outline is this.

Card failures come in two kinds. A soft decline is temporary — insufficient funds, a daily limit, an issuer risk check — and a retry a few days later can succeed. A hard decline is final — a closed, lost or invalid card — and retrying it only generates fees and fraud flags. Retry soft declines; send hard declines straight to a customer notice. Some gateways offer an account-updater service that refreshes reissued card numbers and expiry dates automatically; Stripe and Authorize.Net both list one on their pricing pages.

Dunning is the recovery workflow, and a good one is a sequence with owners and dates rather than a single retry. This calendar is an example to adapt, not a benchmark.

The signals that predict a failure are already in the billing system if payments, invoices and subscriptions are records you can report on: stored payment methods expiring in the next sixty days, prior declines on an account, invoices aging past terms, repeated credit memos, a suspended recurring charge. Turn each into a report and, for high-value accounts, an automated task to the account owner before the renewal date. That is the whole predictive system. For scale, SaaS Capital's 2025 survey puts median net revenue retention near 102% for private B2B SaaS companies with mid-size deals; a point or two of avoidable churn is a real gap at those margins. And measure your own: failed payment rate, recovery rate, involuntary churn rate, days to recover, and invoice aging by bucket.

Testing a gateway before go-live

Use the gateway's sandbox, not a live account with a small charge, and go beyond the happy path. Get sandbox credentials and connect the billing system to them, not to the live keys. Pull the published test card numbers from the gateway's documentation; never use a real card. Run a declined card and confirm the payment record shows Declined with the processor's message and nothing was applied to the invoice. Run an expired card — the failure you will see most in production. Void an authorized payment before capture and refund a completed one from the original payment record; check that the invoice balance and the account balance both move back. Schedule a short-interval recurring charge with two occurrences and let it run; confirm the second payment was created, completed, and the next-payment date advanced. After every step, open the invoice and the account. If any balance takes a manual step to correct, you have found your first production bug early.

How Kugamon handles it

Kugamon's Payment object is one implementation of the native pattern. Stripe, Authorize.Net, PayPal and eWay are configured as processor connections in Kugamon Settings; an org can run one or several, and the terminal skips the processor choice when there is only one. Card and ACH both run through the gateway — ACH through Authorize.Net eCheck and Stripe ACH Direct Debit — and wire and check payments are recorded as manual payments with the reference on the record. A payment can be made only against an Approved or Released Order or an Unsent or Sent Invoice, from a Lightning terminal on the record or by the customer on the Online Order or Online Invoice page. The processor's response sets the status — In Process, Scheduled/Pending, Authorized, Completed, Declined/Error/Expired, Voided, Reversed — with the message in the memo, and Completed amounts apply to the invoice and roll up to the Account balance. Stored payment methods are off by default and enabled by Kugamon Support; once on, a contact's saved method can be marked as default, and a Recurring Charge scheduled from an Approved or Released Order carries the next payment date and Cancel, Suspend, Update and bill-outstanding controls. Refunds are issued from the original payment. Gateway fees are set by the gateway, not by Kugamon. Payments are included in the Quote to Cash and Subscription Billing editions; the payments page has the walkthrough videos.

Keep reading

• Payment gateways for subscription billing in Salesforce — the eight things subscription billing needs from a gateway, the published fees, and the seven-step test plan.
• Involuntary churn: how to stop failed payments from becoming lost customers — why payments fail, the dunning workflow, and the payment data that predicts churn early.
• B2B subscription billing — the invoice-led, contract-led process that payments sit inside.