How to Let B2B Customers Pay Invoices Online (Self-Service AR Portal) in 2026

To let customers pay invoices online, put a payment option on the invoice itself, put a hosted portal behind it that shows the whole account, support bank rails as well as card, and make sure the money lands back on the right invoice in your ledger without anyone rekeying it. Monk does this as one invoice to cash system, so the invoice, the reminder, the payment page and the cash application are the same record rather than four tools stitched together. The checkout page is the easy part. The difficulty sits on either side of it: the buyer who pays out of their own accounts payable system and never opens your link, and the deposit that arrives net of processing fees and no longer matches the invoice it was meant to clear.

Here is the situation most finance teams are in. Invoices go out as an emailed PDF, a minority of customers click through and pay, and the rest pay by ACH push, wire or check on their own schedule, in batches covering several invoices and often with no remittance advice. Accepting payment online is a collections improvement and a reconciliation problem at once, and the second half is where implementations fall over.

Which payment methods do B2B buyers use, and why is card often refused?

B2B buyers pay overwhelmingly by bank rails, and sellers restrict card above a threshold because the interchange cost on a large invoice can exceed the margin on the work.

Card acceptance is priced as a percentage of the value plus a fixed fee, and commercial and purchasing cards sit at the higher end of that range. On a small invoice that is a rounding error, and on a large one it comes out of gross margin, which is why so many sellers publish a policy along the lines of card accepted up to a stated ceiling, bank transfer above it. That policy is legitimate, but it has to be visible at the point of payment. Virtual cards, the single use card numbers emailed by a buyer's AP provider, carry the same cost in a form that looks like a convenience.

ACH is the default rail in the United States and runs in two directions that behave very differently. An ACH debit is a pull: the buyer authorises you, you originate it, and it settles in one or two business days, or the same day using the same day window. Because you initiated it, it can be returned, most often for insufficient funds, a closed account, a stop payment or an unauthorised corporate debit, and returns arrive days after the payment looked successful. An ACH credit is a push: the buyer's bank sends the money and it cannot be reversed, but you have no control over the timing and the remittance detail travels in an addenda record that many banks strip before you see it.

Wire is same day and irrevocable, the normal rail for large and cross border payments, and it costs the sender a flat fee, which is why buyers resist it for routine invoices. Checks persist in construction, healthcare, government and older manufacturing, usually into a lockbox. Offer more than one rail and record which rail each customer uses.

What is the difference between a pay link on an invoice and a hosted payment portal?

A pay link settles one invoice with no login, while a portal is an authenticated space showing the whole relationship, and a serious AR setup needs both.

The pay link exists to remove steps. A buyer opens the emailed invoice, taps a button, chooses a rail, pays, and never creates a password. It should carry the invoice number, the amount and the customer reference through to the payment record so the resulting cash arrives pre matched, and links should be tokenised, unique per invoice and time limited, because an emailed URL gets forwarded, printed and pasted into ticketing systems.

The portal exists to answer questions. It shows every open invoice with its status, the balance split into current and overdue, aging, payment history, statements, credit memos, and the documents that stall payments in practice, most often your W-9 and your remittance instructions. It supports partial payment against a chosen invoice, autopay enrolment, and a place to raise a dispute against a specific line. Send the link on every invoice, and have it land in the portal.

Why will a buyer paying through their own AP system never click your link?

Because their payment is generated by their own AP workflow from an invoice already loaded into their system, so your email is a notification rather than a payment channel.

Large buyers do not pay from PDFs. The invoice is received, coded to a general ledger account and a cost centre, matched to a purchase order and a goods receipt, routed for approval, then paid on a scheduled payment run. That flow happens inside their ERP or a supplier network such as Coupa, SAP Ariba or Tungsten. Across the receivables Monk manages, 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice. For those accounts, a pay link click rate measures the wrong thing.

The fix is unglamorous and effective. Capture the buyer's payment process at onboarding as structured fields on the account: which portal or network they use, the supplier ID, whether a PO number is mandatory, whether a goods receipt is required before approval, what backup must be attached, who approves, and which day the payment run happens. Then submit where the buyer expects it and use email to confirm submission and chase approval. Chasing an invoice that sits unapproved in a portal queue is a different task from chasing one already scheduled for the next run.

Can you surcharge card payments, and how do you handle stored methods and autopay?

Surcharging is permitted in many places and restricted in others, so it has to be checked against card network rules, your merchant agreement, your customer contracts and the law where the buyer sits.

Network rules generally allow a surcharge on credit cards only, not debit, and only after you register in advance, disclose the fee before card entry and again on the receipt, and stay within the cap the networks set. Several US states restrict or ban the practice and the position has shifted through litigation, so one national policy applied uniformly is what catches sellers out. Many enterprise buyers also write a no surcharge clause into their purchasing terms, which overrides your preference regardless of the law. Safer designs are a stated card ceiling or card cost priced into the rate card.

Stored payment methods are a separate discipline. Never hold a card number: use a processor that returns a token so card data never touches your systems. For ACH you hold a mandate, and the mandate is a record rather than a checkbox. Keep the authorisation text the customer accepted, the date, the named authoriser and the amount or frequency agreed, because that record is what defends an unauthorised return claim months later.

Autopay works well for recurring, predictable billing and badly for anything that gets disputed. Send a pre debit notification before the run, cap the automatic amount, exclude invoices with an open dispute or an unapplied credit memo, and choose deliberately between charging on issue and charging on the due date. Retry logic then has to separate soft failures from hard ones. Insufficient funds is worth a retry after a few days. A closed account, a revoked authorisation or a stop payment is not, because each return carries a fee and a poor return rate puts your ACH origination at risk. Make sure a failed autopay reopens the invoice in collections.

What happens to reconciliation when a customer pays online?

The cash you receive stops equalling the invoice you issued, and unless your process expects that, every card payment creates a false short pay.

Take an example. You issue an invoice for 10,000, the customer pays by card, and your processor takes its fee and deposits 9,700. If cash application posts the deposit against the invoice, the invoice shows 300 outstanding and the customer gets chased for it. The correct treatment is to apply the full 10,000 to the invoice, closing it, and post the 300 to a processing fee expense account. That requires the payment record to carry three values, gross, fee and net, and a ledger that accepts a payment whose bank side and invoice side differ.

Batching compounds the problem. Processors settle in payouts, and one payout can cover many payments minus refunds, chargebacks and reserve movements, so the single line on your bank statement matches no invoice and no customer. Reconciliation has to run against the processor payout report, breaking the deposit into its components, matching each to an invoice, then agreeing the total to the bank line. Payment date and settlement date also differ, so around month end that gap splits cash and revenue across periods unless you clear through an in transit account.

Bank rails have their own version. An ACH credit for a rounded amount covering nine invoices, with the remittance stripped by the sending bank, is the classic unapplied cash case. A cross border wire arrives net of correspondent bank charges and converted at a rate you did not choose, producing a shortfall that belongs in an FX difference rather than a collections queue. The rule that keeps this straight is that cash application should never infer the invoice from the amount alone, and that fee differences, FX differences and real short pays are three different things.

What will a finance buyer ask about payment security?

They will ask where card data lives, who can change bank details, and what audit evidence you can produce.

The card question has one good answer: card data should never reach your systems. Use hosted fields or a hosted page from your processor so the data goes straight to them and you hold only a token, which keeps your PCI scope narrow. Expect follow ups about encryption, how portal access is revoked when a buyer's employee leaves, and data retention.

Bank detail change fraud is the risk buyers care about most. The common attack is an email that appears to come from you saying your account details have changed, sent to an AP clerk who updates the vendor master and pays the next invoice to a criminal. Publish bank details only inside the authenticated portal, state on every invoice that details never change by email, require a callback on a known number for any change request, and keep an audit trail of who changed them. The rest of the evidence pack is a SOC 2 Type II report, a penetration test summary, a sub processor list and an incident response process. Monk is SOC 2 Type II compliant, and having that ready shortens a review that would otherwise stall the invoices you want paid faster.

How does Monk handle this?

Monk's Payment Hub is a branded self serve portal for each customer, sitting on the same platform as collections and cash application rather than beside it.

Customers see every invoice and its status, their balances and aging, payment history, statements, credit memos and documents such as your W-9, and they pay by ACH, wire, check or credit card, or enrol in autopay. Because the portal, the reminders and the ledger are one system, a payment made in the portal applies to the invoice and stops the follow up. Monk's AI cash application matches 80% of payments automatically, rising to 95% with suggested matching rules, which keeps netted card deposits and batched ACH credits from becoming a queue of unapplied cash.

For the 92% of enterprise invoices that must be submitted through a vendor portal or network, Monk handles submission in the same flow. Monk integrates with QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, is SOC 2 Type II compliant, and has more than $2B in receivables under management. See the Payment Hub launch, and for the broader case, what a customer portal is and why it matters for AR.

Where should you start?

Run one diagnostic this week: take last month's receipts and classify every one by rail, by whether it arrived with usable remittance detail, and by whether the cash matched the invoice.

Three counts tell you where the problem is. How many payments came through your own payment page against how many arrived by ACH credit, wire or check outside it, which says whether a better checkout is your bottleneck or a distraction. How many arrived without remittance detail and had to be matched by hand, which is your cash application cost in hours. How many card deposits were posted net of fees, because each is a phantom short pay generating reminders for money you were never owed.

Fix the largest count first. Where most cash arrives outside your payment page, capture each customer's AP process rather than redesigning the button. Where most arrives unmatched, invest in remittance capture and matching rules. To see the flow against your own ledger, book a demo.

Frequently Asked Questions

How do I let customers pay invoices online?

Add a payment option to every invoice and reminder, and back it with a hosted portal showing all invoices, balances, statements and documents. Connect the portal to your invoicing so statuses stay live, and carry the invoice reference through to cash application. For enterprise buyers, submit into the portal their AP team pays from.

Which payment methods should I offer B2B customers?

ACH or local bank transfer as the low cost default, wire for large and cross border payments, check where a customer's process requires it, and card for smaller balances. Publish any card ceiling so a buyer does not discover it mid payment, and offer autopay to recurring accounts.

Why do some sellers refuse card payments above a certain amount?

Card acceptance is priced as a percentage plus a fixed fee, and commercial cards sit at the higher end. On a large invoice that percentage can exceed the margin on the work, so many sellers cap card at a stated value and require bank transfer above it. Virtual cards carry the same cost.

Is it legal to add a surcharge for card payments?

It depends on where you and your customer are, and on your network and merchant agreements. Rules typically permit surcharging credit cards only, after advance registration and with disclosure before card entry and on the receipt, within a cap, while several US states and other countries restrict it. Many enterprise purchasing terms forbid it outright.

Why does the cash received not match the invoice on card payments?

Because the processor deducts its fee before depositing, so a paid invoice produces a smaller bank credit. Apply the gross amount to the invoice and post the fee to an expense account. Apply the net instead and the invoice shows a short pay, so the customer gets chased for money they already paid.

What should happen when an online payment or autopay fails?

Distinguish soft failures from hard ones. Insufficient funds is worth a retry after a few days, while a closed account, a stop payment or a revoked authorisation should not be retried, because each return carries a fee and a poor return rate can jeopardise ACH origination. Escalate to a person after the second failure.

What security questions will a finance buyer ask before paying online?

Where card data is stored, whether you hold it at all, how portal access is granted and revoked, and how a change to your bank details would be verified. Use hosted fields so card data never reaches your systems. Have a SOC 2 Type II report, a penetration test summary and a sub processor list ready.