Online Payment Form: The Fields, the Security and the Right Tool

An online payment form is the last screen between a visitor and a sale. Getting it right is less about design than about a handful of decisions: which fields to ask for, who hosts the card inputs, how wallets and 3-D Secure fit in, and what the customer sees when something goes wrong. This guide goes through each one, with the official rules behind them.

What is an online payment form?

An online payment form is a web form that collects payment details, card or wallet, and sends them to a payment processor for authorization. It can be built from plain HTML inputs or from a processor's prebuilt components, and its job is the same either way: collect only what the transaction needs, securely.1Stripe, Payment HTML forms: Best practices for user experience, security, and conversion

In practice, "online payment form" covers three different products:

The rest of this guide applies to all three. The choice between them is covered just below.

TagadaPay: the processor behind Tagada's checkout

If you searched for TagadaPay or Tagada payments, this is the short version. Tagada is a commerce platform for direct-to-consumer brands, and TagadaPay is its own payment processor. Tagada is a checkout, not a form builder: if you need a donation or event registration form, the tools in the next section fit better.

Form builders vs payment links vs checkout pages

Most results for "online payment form" are form builders. Here is what three common tools publish about payments on their own pages, read on October 14, 2026. They change often: check before you sign up.

Whichever you choose, the processor behind it still underwrites your business and sets your fees. How to pick one is covered in our guide to payment service providers.

The fields that matter, and the ones to drop

Stripe's guidance is blunt: a payment form should collect only what's needed to process the transaction, and every extra field is a reason to leave.1Stripe, Payment HTML forms: Best practices for user experience, security, and conversion The core set is short.

Each extra field should pass one test: does the processor, the fraud check, the tax calculation or the delivery need it?

Use the standard autocomplete values on every field, such as cc-name, cc-number, cc-exp, cc-csc and postal-code.11WHATWG, HTML Living Standard, Autofill They let the browser and password managers fill the form, and they matter for accessibility, as you'll see below. With hosted card fields, the processor's iframe sets them for you.

Who hosts the card fields decides your PCI scope

The single most important technical decision is where the card number is typed. If it's typed into an input your own page controls, your website is part of the payment security. If it's typed into the processor's page or the processor's iframe, much less of it is.

For an online store, scope shows up as the self-assessment questionnaire (SAQ) you file each year:

Stripe puts the stakes plainly: a business that handles card data directly may have to meet more than 300 PCI DSS security controls, while the card type, last four digits and expiry date returned after a payment are out of scope and can be stored.8Stripe Docs, Integration security guide The full comparison of gateways is in PCI-compliant payment gateways, and how tokens shrink scope in tokenization vs encryption.

Inside Tagada

See every payment's route, processor by processor

Set the order your processors are tried in, per store, per country or per product.

See how routing works

Apple Pay and Google Pay on the form

Wallets replace the card fields entirely: the customer confirms with Face ID, a fingerprint or a device code, and no card number is typed. Stripe's form guidance recommends supporting them, especially on mobile.1Stripe, Payment HTML forms: Best practices for user experience, security, and conversion

Put the wallet buttons above the card fields, not under them: a customer who can pay with a tap shouldn't scroll past six inputs first. For subscriptions, Stripe recommends Apple Pay merchant tokens so renewals keep working across the customer's devices.9Stripe Docs, Apple Pay

3-D Secure: plan for the challenge

In the EEA and the UK, most online card payments need Strong Customer Authentication, and 3-D Secure is how cards provide it. Elsewhere it's optional and used against fraud. The card issuer decides whether the customer passes silently or gets a challenge: a code, a banking app approval or biometrics. The details are in our guide to payment authentication.

For the form, three facts matter. The challenge appears after the customer clicks Pay. You choose where it shows (a modal, inline or a redirect), but you can't style it: the issuer controls its look.10Stripe Docs, Authenticate with 3D Secure And the customer may leave your page to approve in a banking app.

The common failure isn't the challenge itself. It's the return trip: a session that expired, a cart that emptied, a mobile browser that reopened the shop's homepage. Test the full loop on a phone, with a test card that forces a challenge.

Validation and error messages

Two kinds of errors reach a payment form, and they need different messages. Input errors (a mistyped number, a past expiry date) can be caught before submitting. Declines come back from the issuer after submitting, and the form can only suggest a next step.

Stripe's guidance for input errors: format the card number as it's typed, accept several expiry formats, check the number with the Luhn algorithm to catch typos, check the security code length by brand, mark valid fields, and never clear the whole form after an error.1Stripe, Payment HTML forms: Best practices for user experience, security, and conversion WCAG 2.2 adds that the field in error must be identified and the error described in text, with a suggestion for the fix when one is known.12W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation, December 12, 2024

Validate when the customer leaves a field, not at every keystroke: a red error on the third digit of a card number is noise. Keep the amount on the button and keep it active only when the form can be submitted, with a visible reason if it can't.

Declines deserve their own handling, because some are worth retrying and some are not. That side, including what card network rules allow, is covered in payment acceptance rate.

Accessibility: what WCAG 2.2 asks of a payment form

WCAG 2.2, the W3C's accessibility standard, became a Recommendation on December 12, 2024. Several of its success criteria read like a payment form checklist:12W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation, December 12, 2024

In the EU, the European Accessibility Act lists e-commerce among the services it covers,13European Commission, European Accessibility Act so these criteria are no longer only good practice for brands selling there. Hosted card fields help, but they don't cover your labels, your error messages or your button.

How to make your payment form convert

There's no universal uplift number for any of these changes, and figures quoted without a source shouldn't drive your roadmap. What you can do is fix the causes of hesitation, then measure on your own traffic.

Measure more than the completion rate. Track where customers leave (before the card fields, after a validation error, during 3-D Secure, after a decline), by device and by country. A drop concentrated on one browser or one issuer is a bug, not a design problem. Upsells belong after the payment, not inside the form: see one-click upsells. Broader checkout layout is covered in checkout page design.

How to set up an online payment form

Once the form is live, review it like any other part of the payment stack: when you add a processor, a market or a payment method, the form is where the customer sees the change first.