How to Brand Payment Links: Logos, Colors, and Domains

A branded payment link should help a customer recognize the seller, understand the purchase, and find support. A logo, readable colors, and a familiar hostname can make the handoff clearer. They do not change who sold the product, whether a payment succeeded, or how an order should be fulfilled.

Start with the controls your provider supports and the scope of each setting. This guide uses current Stripe documentation and Square’s Canadian support guidance as concrete examples. Confirm the options available in your own account and market before promising a particular appearance.

Define what needs to match your brand#

Keep amount, currency, product details, taxes, and the actual seller visible. A marketplace should not use a seller’s logo to imply that the seller is processing a charge if the payment arrangement is different. Identify the legal and support information appropriate to the transaction, then select the branding configuration that represents it accurately.

Use documented controls, with their actual scope#

Stripe documents these Payment Links controls in its customization guide. For Square, use Dashboard → Payment links → Settings → Branding, select the location, and configure its supported controls. See Square’s Canadian payment-link settings. Do not assume that a Square Online website-domain feature also applies to a Payment Link.

If you use another provider, obtain the current instructions for its hosted payment-link product. Website checkout, embedded checkout, and hosted payment links can expose different options. A feature missing from a public page is unverified; a support confirmation or account-specific demonstration can resolve it without assuming either availability or absence.

Prepare the assets and choose readable colors#

Keep an approved source logo and export files to the provider’s upload requirements. Stripe currently accepts JPG or PNG icons and logos below 512 KB, with dimensions at least 128 by 128 pixels. Its icon is square, while a non-square logo can replace some uses of the icon. Check the current account branding requirements before uploading.

Use the hosted page’s supported appearance controls rather than expecting arbitrary CSS, a completely custom layout, or every brand font. Save the prior settings and approved asset files so a correction is straightforward. Check how the selected logo behaves on the available background, especially if the artwork contains white lettering or transparent margins.

For ordinary text, WCAG’s minimum contrast criterion generally requires 4.5:1; qualifying large text requires 3:1. Logos have an exception, but ordinary payment-page labels do not gain that exception merely because the brand guidelines specify their color. Check the button label, form instructions, error messages, and policy links. See W3C contrast guidance.

Before release, inspect the payer experience on the devices and browsers your customers use. Include keyboard focus, a declined-payment message, and a longer product name. These checks are part of operating the payment page; a successful logo upload alone cannot establish that the purchase remains understandable.

Set policies and support details alongside the visuals#

Stripe supports policy and contact information through Checkout and Payment Links settings, using the business’s public details. Its Payment Links guide also describes requiring a terms-of-service checkbox when a terms URL is configured. Review the actual policy URLs and support destination, rather than treating the presence of a footer as sufficient evidence.

Open each destination as a customer would. Catch draft policies, staging domains, sign-in requirements, redirect loops, or a policy for the wrong seller. Keep the support address monitored and ensure the confirmation message explains the next step. For subscriptions, describe the charge cadence and cancellation route in the information appropriate to that offer.

Add a custom domain with a plan for links already shared#

Stripe supports custom domains for Checkout, Payment Links, and the customer portal. Its support FAQ lists US$10 per month, with local-currency billing where available. A subdomain such as pay.example.com provides a recognizable host while Stripe continues hosting the payment page. See Stripe’s custom-domain FAQ.

Assign someone with DNS access to follow the exact records and verification instructions shown in the provider’s setup. Do not point the payment hostname at an unrelated app server or invent DNS targets from an old example. Wait for the provider’s ready status, then confirm that the resulting link opens securely and reaches the intended purchase.

Inventory every place the payment URL appears: invoices, emails, text messages, QR codes, campaign pages, and saved customer bookmarks. A domain change has a distribution problem as well as a configuration problem. Updating the link in your website does not replace the URL printed on an invoice already sent.

Stripe states that disconnecting its custom-domain subscription stops payment and portal links using that domain from working. You can copy and share new provider-domain links for the existing links. Therefore, a rollback plan must include replacement URLs and customer communications; cancelling the domain is not an automatic redirect for old links.

A branded payment hostname also does not change the receipt-email sender. Stripe documents custom email domains separately. Keep the hostname, customer emails, confirmation page, and merchant identity as distinct settings so the team does not promise that one change covers all four.

Do not confuse a branding rollout with traffic isolation#

Stripe says account branding applies across the account and takes effect in many places, including hosted payment surfaces. Editing those defaults is not a limited experiment simply because the team sends only one new link afterward. Existing links and other surfaces may share the changed settings.

Use a provider-supported isolated test environment or a verified scoped override when you need a limited evaluation. If neither applies, schedule the account-wide change with the owners of affected surfaces and sample existing links afterward. You can phase distribution of new URLs, but that controls who receives those URLs; it does not isolate an account-wide appearance change.

For Connect, direct charges generally use the connected account’s branding. Indirect charges without on_behalf_of generally use the platform’s branding; setting on_behalf_of changes the usual branding source, subject to explicit overrides. Confirm the actual integration in Stripe’s Connect branding guidance instead of choosing a logo by payment-link ownership alone.

Keep payment confirmation separate from checkout completion#

A return page is not proof that the order was paid. Stripe’s fulfillment guide applies to Payment Links and requires checking the Checkout Session’s payment_status. Some delayed methods complete checkout while payment is still processing; success or failure arrives later. A customer can also pay successfully without ever reaching your return page.

For example, a $120 order paid by a delayed method can reach a branded confirmation page before funds are confirmed. Show that the payment is pending and withhold the paid entitlement until success. If it later fails, preserve that outcome and offer the appropriate retry path. A color or hostname change should never bypass this rule.

Stripe can deliver duplicate events and does not guarantee their order. Verify signatures and retain event IDs, as described in its webhook guidance. Also protect the business action itself: two different notifications about the same purchase must not grant two entitlements or create two accounting records.

A practical implementation stores the valid event durably before acknowledging it, then uses a transaction or equivalent durable mechanism to save the purchase transition and an outbound work item together. A worker can retry delivery using a stable business key. This is an implementation recommendation: marking an event processed in memory before saving the action creates a loss window if the process crashes.

If several Checkout Sessions can pay the same internal order, a unique session ID alone is not enough to protect that order. Map sessions to the intended purchase and enforce its one-time fulfillment rule. Where a second payment actually occurred, investigate and handle the excess payment explicitly rather than erasing it as a duplicate notification.

Release with a short, useful record#

• Save the previous asset files, settings, and affected account or location.
• Record the new files, colors, policy URLs, and domain status.
• Identify affected existing links and other hosted surfaces.
• Check an immediate success, decline, and delayed payment where supported.
• Confirm that fulfillment and reconciliation follow the actual payment state.
• Prepare replacement URLs if a domain must be disconnected.

Compare completion and support rates using clear denominators. If 100 eligible checkout sessions produced 60 successful purchases before a change and 75 afterward, completion rose from 60% to 75%: 15 percentage points, or 25% relative growth. Those illustrative counts do not prove branding caused the improvement; payment-method mix, traffic source, pricing, and timing can also change.

Keep the first release small in scope where the provider actually permits it. If a shared setting causes a problem, restore the relevant setting and check the affected surfaces. If a custom-domain URL has already been distributed, include those recipients in the recovery plan rather than assuming a settings rollback fixes their links.