Payments

Payments let a form collect money from the visitor through Stripe or PayPal before the submission is finalized. The form's side-effects (notification emails, integrations, registration, confirmation emails) fire only after the payment is confirmed, so an abandoned or failed payment never produces a "real" submission.

Card data never touches your server: both providers use their hosted checkout pages, so there is no PCI scope to manage, and Stripe handles SCA/3-D Secure (and Apple Pay / Google Pay) automatically.

Set up provider credentials

Credentials are stored once for the whole site, not per form. Open Components → NXP Easy Forms → Options → Payments and fill in the provider you want to use:

• Stripe — publishable key, secret key, and webhook signing secret (separate test and live values).
• PayPal — client ID, client secret, and webhook ID (separate test and live values).

Secret keys and webhook secrets are encrypted before they are stored. Publishable keys and the PayPal client ID are public by design and are sent to the browser as part of the checkout.

Because credentials live at the site level, you can move a single form from test to live without re-entering any keys.

Enable payments on a form

Open the form, go to Form Settings → Payments, and turn payments on. Payments are off by default. Configure:

• Provider — Stripe or PayPal (one provider per form).
• Mode — test or live.
• Amount — fixed, a Price field, or a Calculation field (see below).
• Currency — pick from the supported ISO-4217 currencies.
• Description — shown on the provider's checkout and receipt. Supports {{form_title}} and &#123;&#123;field:<name>&#125;&#125; placeholders.
• Cancel redirect — an optional same-site URL the visitor returns to if they abandon checkout.

The Payments tab is hidden entirely on the free edition.

Setting the amount

The charged amount is always resolved on the server from the form's saved configuration, never from values posted by the browser, so a tampered page cannot change what the visitor is charged. The amount is locked in when checkout starts, so editing the form afterward never changes an order already in progress.

Three modes:

• Fixed — a single amount you set on the Payments tab.
• Price field — bind the amount to a Price field on the form (for fixed product/option pricing).
• Calculation field — bind the amount to a Calculation field so the total can depend on the visitor's answers (quantities, options, and so on).

Webhooks

A webhook is how the provider tells your site the payment completed. This is required for payments to work. In the Options → Payments screen, each provider and mode shows the exact webhook URL to copy into the provider's dashboard.

Subscribe to these events:

• Stripe — checkout.session.completed and payment_intent.payment_failed.
• PayPal — PAYMENT.CAPTURE.COMPLETED and PAYMENT.CAPTURE.DENIED.

Submission statuses

Payment-enabled forms always store a submission row so the payment can be tracked, even if general submission storage is off. The submission carries a payment status, shown as a badge with its own column and filter in the Submissions list:

Status	Meaning
Pending payment	Submitted; awaiting the provider's confirmation
Payment completed	Paid and all side-effects dispatched
Payment failed	Declined card, insufficient funds, or denied capture; not charged
Payment expired	The checkout session timed out before completion

A completed order whose follow-up actions hit a problem (for example an integration timing out) stays Payment completed with a warning indicator. It is never flipped back to failed, because the money was captured.

When the license is inactive

Payments are hard-gated. Unlike most Pro features, a payment form does not keep running if the license lapses: the Payments tab and the runtime payment step are both switched off, and a visitor sees a clear "payment not available" notice instead of submitting. Your saved credentials and settings are preserved, so re-activating the license restores the form without re-entering anything.

Not included in this version

• Subscriptions or recurring billing.
• Coupon codes, deposits, or partial payments.
• Tax calculation.
• Refunds from inside Joomla (issue refunds from the Stripe or PayPal dashboard).
• More than one provider on the same form at once.