To set up Payment Page, install the plugin, start the intended gateway connection, configure one form's pricing and fields, choose its post-payment actions, and publish it with a shortcode or Elementor. Complete the provider's test flow before accepting live payments; setup time varies with the site and gateway onboarding.

Before you start

Check WordPress.org for current compatibility requirements. Decide whether this page will collect a one-time payment or a supported recurring Stripe payment, what information the payer must provide, and what should happen after payment. Keep live customer data and production credentials out of demonstrations and test environments.

This tutorial covers the Payment Page setup workflow. It does not replace Stripe or PayPal onboarding requirements, and the presence of a method in WordPress does not prove that a provider has enabled it for a particular account or transaction.

1. Install the public plugin

Install and activate Payment Page from WordPress.org, then open its administrator screen to begin configuring the plugin.

2. Start the gateway configuration

For Stripe, begin with the Connect control in Payment Page and complete Stripe's onboarding for the account that will operate the form. For PayPal, configure the separate PayPal Standard Checkout gateway. PayPal is one-time only in Payment Page; recurring plans use Stripe.

Gateway availability, verification, methods, fees, balances, and payouts are provider-controlled. Use the appropriate provider test mode and do not infer a successful connection solely from the local settings screen.

3. Create or import a form

Create a Payment Page form from scratch or choose a Payment Form Template.

A Payment Form Template is a starting configuration. Review its amount, currency, fields, labels, gateway choices, and actions before publishing it for a real use case.

4. Configure pricing and billing

Set a fixed amount when the price is known, or let the payer enter a custom amount when appropriate. Stripe plans can be one-time, daily, weekly, monthly, quarterly, every six months, annually, or every three years. These are the supported schedules; arbitrary custom frequencies are not included.

Currency and method compatibility depend on the connected account, country, payment method, and whether the charge is one-time or recurring. Confirm the actual combination in the provider's test environment.

5. Add only the fields the payment needs

Use customer fields for payer information and custom fields for relevant non-card details such as an invoice reference, dedication, or project name. Supported fields can be prefilled through query parameters. Do not use ordinary custom fields to collect card numbers, bank credentials, passwords, health details, or other information the workflow does not need.

6. Configure the result

Choose the success and failure messages, and configure a confirmation email, redirect, or successful-payment HTTP action only when the workflow requires it. Confirm that customer-facing text explains what was received and what happens next without promising a provider-controlled settlement time.

7. Publish and test the complete path

Copy the form shortcode into the intended WordPress page or select the form in the native Elementor widget. Check the published page with keyboard navigation and at desktop and mobile widths. Then test validation, eligible payment methods, success and failure handling, email configuration, and redirects in the appropriate provider test environment.

For a concise map of these stages, see How Payment Page works. The form-builder overview, confirmation and redirect guide, and Payment Form Templates document the individual controls.