How to test an invoice payment link properly

If you searched for “test invoice payment link trades”, the main point is simple: do the check in test mode, prove the full payment path, and keep live charging and real customer sends out of it.

That matters because an invoice link can look fine and still fail where it counts. The page might open, the branding might load, and the amount might appear correct, but none of that proves the invoice will actually move to paid when someone completes payment.

For UK trades firms using HighLevel with Stripe, the safest approach is to test five things in order: invoice identity, amount, currency, link destination, and payment-status update. Then run one stopped or failed payment path as well.

Start in test mode, not live

HighLevel supports Stripe in both Test Mode and Live Mode, and payment-method settings can differ between those environments (HighLevel Stripe setup). That means a method you see in live might not appear in test, or the other way round, depending on your setup and Stripe eligibility.

HighLevel’s invoice guidance also makes a useful distinction: the invoice editor preview is not the final customer view, and copying or sending an invoice link creates a dynamic payment link and moves the invoice on from Draft (HighLevel invoice guide). In other words, do not treat the editor screen as proof that the customer-facing page is right.

So the first rule is straightforward: switch to test mode first, use an internal test record rather than a live customer send, and keep this whole exercise away from real collections.

Know what a real test proves

A proper test has two separate parts.

First, the customer-facing page must be the right one. Stripe separates the hosted invoice page from the invoice payment result. A finalised invoice can have a hosted_invoice_url, while the invoice itself has its own status such as draft, open, paid, uncollectible, or void (Stripe invoice object).

Second, the payment must complete and update status. Stripe also documents invoice payment events such as invoice.paid, invoice.payment_succeeded, invoice.payment_failed, and invoice.payment_action_required (Stripe events, Stripe invoice object).

That is the key distinction busy office teams often miss:

• A page loading proves destination and rendering.
• A successful test payment proves end-to-end payment handling.

You need both.

Use this test-mode checklist

Use one line per invoice test. Keep it short enough that someone can fill it in while the check is happening.

Scroll sideways to see all columns.

If you already use a handover sheet for admin jobs, add these columns there rather than making a new document no one maintains.

Run the test in the right order

A clean sequence saves rework.

1. Check the environment

Confirm you are in Test Mode in both systems. In HighLevel, Stripe test and live settings can differ, including available methods (HighLevel Stripe setup). If a method is missing in test, note that as an environment difference before you assume something is broken.

2. Build or open the invoice in draft

Review the invoice record itself first. Check the customer identity, site address, job reference, line items, total, and currency before you touch the link.

This sounds obvious, but it prevents blaming the payment link for a bad invoice setup.

3. Use the proper preview

HighLevel’s invoice editor preview is useful for layout, but it is not the final customer-facing page. Open the fuller invoice preview or the actual dynamic invoice link view for a real check (HighLevel invoice guide).

At this stage, you are proving identity, amount, currency and layout.

4. Open the link on more than one device

Open the copied link on desktop and mobile. You are checking that the destination is correct, the page loads, and the invoice shown is the intended one.

If it opens but shows the wrong invoice, the test has failed.

If it opens and looks right, the test is only half complete.

5. Complete one real test-mode payment

Now finish a genuine test-mode payment using the payment method Stripe documents for testing on your account. Do not skip this step.

After completion, check the invoice status in your platform and, where relevant, in Stripe. A proper success test should show the invoice moving into the paid state, or a corresponding success event such as invoice.paid or invoice.payment_succeeded (Stripe invoice object, Stripe events).

6. Run one stopped or failed path

Repeat the test, but this time stop part-way through or use a documented test-failure path for the method you are checking. The invoice should remain unpaid or open, and Stripe may show a failure or action-required event (Stripe events).

This proves you will not accidentally treat an incomplete payment as settled.

Examples

Example: the page loads but the test is not finished

You copy the invoice link, open it on a phone, and the customer-facing page shows the right name, job reference and total. That is a pass for destination and display.

But after a test payment, the invoice still shows open. No paid status appears. That means the link itself is not the issue. The fix owner is now the payments or integration owner, because the end-to-end payment confirmation did not land.

Example: the preview is right, the hosted page is wrong

The invoice editor preview shows the correct site address and due date. You then open the fuller preview or payment link and spot an older site address.

Stop there. Do not test payment yet. The invoice creator needs to correct the invoice identity first, then restart the check from preview.

Example: the failed path protects you properly

You run the link in test mode and stop before finishing payment. The invoice stays open. On a separate run, you use a failure path and the invoice still does not move to paid.

That is the result you want. It shows your process can tell the difference between a customer opening a page and money actually being collected.

Common faults and who should own them

Most failed checks fall into one of three buckets.

Admin setup fault

Wrong customer name, old address, wrong line items, wrong due date, or wrong amount. These are usually invoice-record problems, not payment-provider problems.

Platform or branding fault

The link opens to the wrong page, the wrong invoice, or an outdated layout. Start with the person who owns invoice setup inside HighLevel.

Payments or integration fault

The page opens and payment completes in test mode, but the invoice status does not update. Or a failed payment path marks something as paid when it should not. Those need the payments owner to check the Stripe and HighLevel connection.

What you can do today

• Switch your Stripe and HighLevel setup to test mode.
• Create one internal test invoice, not a live customer send.
• Check the final preview or hosted page for identity, amount, currency and destination.
• Run one successful test payment and confirm status changes to paid.
• Run one stopped or failed path and confirm status stays unpaid or open.
• Log the result, the owner of any fix, and whether you need to retest.

If your invoicing process still feels patchy after that, tidy the wider admin flow around it. Our payments and invoicing service explains where that work usually sits, and pricing shows how UKTL packages its support.

For the rest of your setup, browse more practical admin fixes in our guides. These three are a good next step:

• How long to block for a quoting site visit
• Customer CRM fields for trades: a simple template
• What do trade leads cost? Checkatrade, Bark and MyBuilder compared

A short, recorded test now is better than finding out on a real invoice that the page opened but the payment never landed.

Keep building your enquiry process

See our guides for trades for the wider picture, explore payment and invoice setup with UKTL and check the current package and pricing.

• How long to block for a quoting site visit
• Customer CRM fields for trades: a simple template
• What do trade leads cost? Checkatrade, Bark and MyBuilder compared