URL Parameters

Payment Links support prefilling customer and payment fields via URL query string so merchants can generate per-customer or per-invoice links without building a backend integration.

Example

http://pay.sandbox.b2bpay.com.au/1337?customerName=Ian&paymentAmount=2.00&customerEmail=x@x.com

The merchant builds the URL (typically from a template in their CRM, invoicing system, or email platform) and shares it with the customer. When the customer opens the link, the hosted page loads with the values already filled in.

Supported parameters

Query-string parameter names are case-insensitive, but camelCase is the canonical form. The parameters below map directly to fields on the Payment Link form — values passed in the URL are pre-filled when the page loads.

Always-available fields

Parameter	Type	Required	Notes
customerName	string	✓	Customer's full name
contactNumber	string	✓	Numeric only, 6–15 digits
paymentAmount	decimal	✓	In dollars (e.g. 2.00). Minimum 1.00.
customerReference	string	✓	Merchant-supplied reference for reconciliation

Program / merchant-configurable fields

Whether these fields appear on the Payment Link depends on the merchant account and program configuration. If the field is hidden in your program, the URL parameter is ignored.

Parameter	Type	Notes
customerEmail	string	Email format validation when present
companyName	string	Max 250 chars
australianBusinessNumber	string	ABN format
additionalReference	string	Optional secondary reference
reference1	string	Max 40 chars, hidden by default
reference2	string	Max 40 chars, hidden by default

SlicePay-only fields

Available when SlicePay is enabled on the merchant account (TravelPay merchants).

Parameter	Type	Notes
departureDate	date	Only applicable for SlicePay

Card details (PAN, CVV, expiry), bank account details, and any sensitive credentials cannot be pre-filled via query string — customers always enter these directly on the hosted page.

Locking fields with state=disabled

Appending &state=disabled to the URL greys out the form fields so the customer cannot edit the prefilled values.

http://pay.sandbox.b2bpay.com.au/1337?customerName=Ian&paymentAmount=2.00&state=disabled

Security: prefill values are hints, not server-signed

Query-string parameters are prefill hints only. They are not cryptographically signed and not server-enforced.

• A customer who edits the URL can change any prefilled value.
• state=disabled is a cosmetic UI lock — it greys out the fields but does not enforce the values server-side. A user with basic browser dev tools (or who simply removes state=disabled from the URL) can edit the fields freely.
• Do not rely on URL parameters for trusted amount locking. If a customer must not be able to change the amount (invoice collection, fixed-price products, etc.), use Hosted Checkout with a server-generated fingerprint instead. The fingerprint is cryptographically tied to the amount and will reject any client-side tampering.

When to use URL parameters

Good fits:

• Pre-filling customer details to reduce form friction
• Per-invoice links where the amount is a convenience default (not trust-critical)
• CRM/email-merge templates that generate payment URLs

Poor fits:

• Any scenario where the amount must be trusted — use Hosted Checkout instead
• Per-customer tokenisation flows — use Hosted Checkout Mode 1
• Refund or backend operations — use the REST API

Related

• Payment Links Overview
• Setup & Branding
• Hosted Checkout — for server-signed amount locking
• Hosted Checkout — fingerprint generation