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
Team: 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 problem

Previously, the only way to pay invoices was a multi-step process requiring the user to login, navigate to “open invoices,” select invoices they would like to pay and initiate the payment process from there. This process created frustration for users that wanted to quickly pay a single invoice.

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

Payments made easy

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

Redesigning payment method component for better security

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.