Online payments in the customer portal: collecting an invoice in one click

It is 9:40 on a Tuesday. The person handling your receivables opens four near-identical emails: "Could you resend the invoice?", "Are your bank details still the same?", "I sent the transfer, receipt attached", "Which quote does this invoice belong to?" All four create the same work: someone finds the invoice and exports a PDF, someone opens the bank statement and matches an amount, someone ticks a paid box by hand. Three screens, three people and half a day of delay for one invoice, which on the customer's side is a single line: an outstanding balance and a date.

This article is about the flow that stops those emails from ever being written: the customer sees the invoice in their own portal, pays on the same screen, and the record closes itself the moment the provider confirms. In order: why the pay button belongs next to the invoice, what "one click" actually consists of, the decisions you owe yourself before you turn payments on, a table for choosing a method, what has to change in the record when confirmation arrives, partial collection, failed payments and refunds, security and contract terms, and the numbers that tell you whether any of it worked. We will not quote commission rates, prices or statutory clauses; confirm those against your payment provider's contract and with your accountant.

Why does the pay button belong next to the invoice?

The Invoices tab of the customer portal lists finalised, sent, partially paid and paid invoices in date order. That list informs, but it does not finish anything. When someone sees a line reading "outstanding for 20 days" and decides to settle it, a missing action button pushes that intention into another channel: they open a banking app, hunt for account details, message your team, and then forget. A large share of late payment is friction between intention and action, not a decision not to pay.

The same logic applies outside the portal, which is why a single-use payment link sent inside a conversation works: it removes distance. The difference is durability: a link is minted for one transaction and expires, while a portal is a permanent address. Three months later the customer returns and finds the old invoice, its status and its document in the same place.

The portal's Invoice PDF Download behaviour completes the picture: each invoice is available as a document generated only for that customer's own record, so both the "please resend it" email and the "where do I pay" question close on the same screen. Putting the pay button next to the invoice is an operational decision that shortens days sales outstanding, not a design preference.

What does "one-click payment" actually consist of?

The customer sees one click; behind it sit at least six steps. First, identity: with Passwordless Login (Magic Link) the customer enters an email address, clicks the single-use link that arrives, and the session opens. There is no password, so no payment is abandoned over a forgotten one. Second, visibility: the customer sees only finalised documents tied to their own record. Third, locking the amount: the figure charged is read from the balance held on the server, never from a value posted by the browser.

The fourth step is the handover to the provider, the fifth card authentication, the sixth the confirmation coming back. For enterprise buyers who want identity handled centrally, consolidating authentication behind single sign-on is a separate exercise; in the portal the goal runs the other way, giving the customer a secure window without an account at all.

Once six steps feel like one click, customers expect the same everywhere else. Someone who settles an invoice in two seconds wants to confirm an appointment just as fast, which is why the portal's Appointment Confirmation and Rescheduling flow is built on the same principle and lands in the same record as inbound booking links that write straight from the calendar into the CRM. The value of self-service is never in one transaction; it is in every routine transaction finishing in the same place.

What do you need to decide before switching payments on?

Five decisions arrive before any integration work. Which provider you will work with, which sets your commission structure, currency coverage, instalment options and settlement day at once. Whether partial payment is allowed. Who absorbs the cost of instalments. Which invoice statuses are eligible for payment. And on which day funds land versus which date the transaction is booked in your ledger.

None of these can be settled from a generic "best provider" list, because all of them are contractual. To compare payment gateways and methods while building your collection stack you need your own transaction volume, average invoice value and refund frequency in front of you. Read the rates and settlement terms out of your provider's contract, and have the bookkeeping treatment confirmed by your accountant.

Settle one point early: whether you pass the processing cost to the customer is contractual as much as commercial, and card scheme rules on surcharging differ by market. If the figure shown in the portal does not match the figure on the customer's statement, you will spend several times the recovered fee on disputes and support threads.

Which collection method suits which situation?

No single method fits every invoice. The table below summarises where each route earns its place in a portal-led collection process and what it costs you operationally. Any thresholds you set around it should come from your own average invoice value and refund rate.

Method	Best fit	Operational cost
Card payment inside the portal	Recurring mid-value invoices where the customer already uses the portal	Processing fees; refunds run through the provider
Payment link	Customers not yet on the portal; one-off collection inside a chat or email	Link expiry and follow-up tracked separately
Bank transfer	High-value corporate invoices	Manual reconciliation and receipt matching
QR code payment	On-site delivery, field service and in-store collection	Keeping printed material current
Recurring card charge	Subscriptions and maintenance contracts	Card expiry and failed-charge handling

The QR route pays off in the field: a team that knows how to generate a QR code for a menu, a payment or a business card can close collection at the moment of delivery. But if the address behind the code is not tied to the invoice record, you hand the speed back during reconciliation.

What must change in the record when the provider confirms?

The portal's Online Payment behaviour describes the real gain: a payment page opens for an accepted quote, and the record is marked paid the moment the provider's confirmation arrives. The second half of that sentence is the important one: what closes the record is the provider's confirmation, not the thank-you page the customer happens to see. That distinction stops a payment from looking lost when a browser tab closes or a connection drops mid-redirect.

The second gain is traceability. The portal's Activity Log writes views, messages, revision requests and payments one by one, and Instant Notifications reach your team as events happen, without a double click producing two notifications. Expect the same on the payment side: if one transaction is reported twice, the record must not close twice.

Payment integration is a record-keeping discipline rather than a button. When you design a setup that writes every payment back onto the customer record, keep the transaction id, amount, currency, provider reference and timestamp on the same row. On settlement day that row is the only thing that answers "which invoice was this money for".

How should partial and instalment payments appear in the portal?

Invoices do not always close in one go, which is why the portal's invoice list carries partially paid as a status of its own. When a customer pays part of an invoice, what they should see is the remaining balance, not a blunt "unpaid". Any threshold you set here — a minimum first payment, a cut-off for instalments — should come from your own average invoice value rather than a borrowed rule of thumb.

Where the amount is calculated decides whether this holds up. In the portal's Partial Quote Acceptance behaviour the customer can accept only the line items they choose, and the accepted total is recalculated on the server. Collection needs the same rule: the outstanding balance is computed server-side, because in the meantime another payment may have landed, a refund may have been processed or a discount applied.

Partial payment also gives you a pricing lever. Designing an early payment discount alongside late payment terms visibly moves customers who can see in the portal that the amount depends on when they pay. Whether the discount belongs on the invoice or in a separate entry has accounting consequences, so confirm that with your accountant.

Who owns failed payments, refunds and chargebacks?

The most neglected part of any payment flow is what happens when the transaction fails. One card is declined for insufficient funds, another because authentication was abandoned halfway, a third by the issuing bank's risk rules. The customer sees "payment failed" and usually does not try again. A failed transaction must never be a silent event: it should reach your team, be written to the record, and produce a reminder after a sensible interval.

Refunds are separate. A refund returns money through the provider; a chargeback is started by the customer's bank and carries its own evidence and deadline rules. Decide how each reflects on the invoice status in the portal — leaving a refunded invoice marked paid creates a discrepancy nobody can unpick three months later.

For receivables that keep failing, the question stops being payment flow and becomes accounting policy. Knowing how provisioning for doubtful receivables works also tells your collections people when to stop chasing and hand the record on. Set thresholds and ledger treatment with your accountant.

How do you set up payment security and contract terms in the portal?

Portal-side security sits in two layers. The session is the first: with Secure Access, a session opens on a separate 24-hour token that never crosses into normal API access, and when it expires the customer requests a new link. No permanent password is ever created, so there is none to steal. The login screen is the second: Non-Disclosing Login does not reveal whether the address entered exists in your system, so the portal cannot be used to enumerate your customer list.

On card data the rule is simple: details never sit in your system, they are entered on the provider's page, which moves both attack surface and compliance burden to the provider. The portal's Finalised Documents Only behaviour is the same discipline: draft quotes and draft or cancelled invoices never reach the portal, so customers see only what is final and payable.

Contract terms are a legal matter, not a product one. What a remote buyer must be told, and when, is defined by the terms you publish; the equivalent of a distance selling agreement and its scope should be in place before you open a payment screen. The portal's E-Signature behaviour seals the signer's name, timestamp and IP address into the record, but which signature type a document legally requires is a question for your legal adviser.

Which numbers tell you whether portal payments worked?

Once payments are on, the metric that matters is not clicks but how long money takes to reach your account. Four numbers are enough for most teams. Days sales outstanding: the average days between issuing an invoice and receiving funds. Portal share: how much of collected revenue came through the portal. The first-48-hours rate: invoices settled within two days of being seen. And the failure rate, with how many failures close on a second attempt.

Read together, they separate an infrastructure problem from a behavioural one. A high failure rate points at the payment stack; a low portal share with payments still arriving on time points only at channel habit. To identify slow payers early, scoring payment risk to see which customers will pay late beats raising reminder frequency across the board.

To try this flow against your own invoices, open a free Rocketly account and switch the customer portal on for a single customer first. Measure from month one; the effect of putting payment next to the invoice is invisible without a before and after.

FAQ

Does the customer need an account to pay?

No. Portal access runs on a single-use link, so the customer creates no password and installs nothing. The link is valid briefly and works once; the session then runs on its own portal token.

What happens to the invoice if confirmation never arrives?

The record stays open. Invoice status is changed by the provider's confirmation, not by what the customer saw on screen, so until it lands the invoice stays outstanding and on the collections list.

Can we pass the processing fee on to the customer?

That is contractual as well as commercial, and surcharging rules vary by market, provider and card scheme. Confirm it against your payment provider's contract and with your accountant before implementing it.

Can the portal track customers who pay by bank transfer?

The invoice status is visible in the portal, but matching a transfer is a reconciliation task against the bank statement. The customer sees paid as soon as the match is written to the record; if matching lags, they see an outstanding invoice they have already settled, and they will email you about it.