Product design · B2B payments

Airgas One Time Payment

$368,744 in payments completed within the first month of launch

Duration: July – Nov 2024
My role: Senior Product Designer; sole designer on the feature, working with 2 PMs and the dev team
Tools: Figma

Customers who just wanted to pay one invoice had to log in and navigate a multi-step process. I designed a guest payment flow that pays an invoice without an account, and designed deliberately for the security risk that opening payments to anonymous users creates. $368,744 in payments were completed in the first month after launch.

The real problem

Paying an invoice required logging in, navigating to open invoices, selecting invoices, and initiating payment from there. For customers who pay a single invoice occasionally, or whose accounts payable person isn’t the account holder, the login wall was the friction, not the payment. The problem wasn’t “make payment faster”; it was “make payment possible without an identity.”

The old Airgas bill-pay experience: an invoice list inside the logged-in account area — Before: paying an invoice meant logging in and navigating to open invoices first.

Decision 1

Invoice details as lightweight authentication

A guest has no login, but they do have the invoice. The flow verifies the payer by matching invoice and account details: enough proof of legitimacy to accept money against the right account, without creating an account. That’s what makes guest payment viable at all.

Finding those numbers is the guest’s whole task, so I made it as easy as possible: an annotated invoice at the entry point that points out exactly where the invoice number and Sold To number live on the paper invoice.

Annotated Airgas invoice with callouts highlighting where the invoice number, invoice date, and Sold To number appear on the remittance slip — The guide at the entry point: exactly where the invoice and account numbers live on a real invoice.

One Time Payment guest entry screen with invoice and account fields, the annotated invoice guide alongside, and a captcha verification step — The entry point in context: invoice and account details with the guide alongside.

One Time Payment captcha step completed successfully, shown on a phone — The entry step on mobile.

Decision 2

Fast by default, flexible when needed

The payment amount is pre-filled with the current balance; the majority case is “pay what I owe.” Partial payment is an explicit option rather than the default, keeping the fast path fast without trapping customers who need to pay less.

The screen itself deliberately mirrors the logged-in payment experience, so paying as a guest feels familiar rather than new.

Pay Invoice screen with the payment amount pre-filled to the invoice's current balance — The fast path: payment amount pre-filled with the current balance.

Pay Invoice screen with a partial payment amount entered, lower than the current balance — Partial payment as an explicit option rather than the default.

Decision 3

Entry from the header

One Time Payment is linked from the site header rather than buried in account navigation, so a guest can reach it from any page without understanding Airgas’s account structure. Discoverability was the argument I made for the header placement, and it proved out: over 50% of users who start a payment enter through the header link on the homepage.

Airgas homepage header with the One Time Payment link highlighted beside the Register and Login links — The entry point in the site header, reachable from any page, no account knowledge required.

Decision 4

Asking for the security code

The payment-method modal predated this project, and it never asked for the card’s security code. Opening payments to the public internet raised the bar on card handling, so I redesigned the modal to require the security code: one small added step for the customer that strengthens the security of every card payment.

The old Edit Payment modal asking only for name on card, card number, and expiration, with no security code field — Before: the existing payment modal collected card details with no security code.

The redesigned Enter Credit Card modal with fields for name, card number, expiration, and a required security code — The redesign: security code required on every card entry.

Failure states

If the invoice and account details don’t match, the form returns an inline error and the customer can correct and retry; a payment is never initiated against an unverified invoice. Keeping failure recoverable in place mattered here: a guest who hits a dead end has no account to fall back on, so the form is where the problem has to get solved.

One Time Payment entry form showing the inline error 'Invalid invoice number. Please try again.' above the invoice number field, with the entered values preserved — Failure kept recoverable in place: an inline error, the entered details preserved, correct and retry.

The payment step has its own guardrail: an editable amount can exceed the balance, so the form catches it inline, and an invalid amount never counts toward the payment total.

Pay Invoice screen with $11,000 entered against a $10,000 balance, showing the inline error 'Please enter a payment amount that does not exceed the balance' and a payment total of $0.00 — The money step's guardrail: amounts above the balance are caught inline, and nothing counts toward the payment until corrected.

Outcome

$368,744 in payments were completed within the first month of launch.

We didn’t set a launch target, and I didn’t have access to a share-of-total-payment-volume baseline, so I’ll say plainly what that number is: real money through a channel that didn’t exist before. What I’d measure next: One Time Payment’s share of total payment volume, whether repeat guest payers convert to accounts, and whether it cannibalized Autopay enrollment or served a different population entirely; my hypothesis is the latter, since the users are different (occasional payers vs. account managers).