Setting Up PayPal Payments in WordPress: Forms, One-Time and Recurring Payments

Web · Published 2026-10-27

To accept PayPal in WordPress, pick a plugin that matches what you sell (a store, a donation or order form, or a membership), connect it to a PayPal business account through PayPal's REST app credentials or the plugin's onboarding flow, test everything in PayPal's sandbox, and confirm payments on the server through webhooks before delivering anything. One-time payments and recurring payments use different PayPal APIs, so check that the plugin supports the flow you need before you build the form.

This guide stays general on purpose: plugin interfaces and PayPal's dashboards change often, and fees and availability depend on your country and account. Follow the current documentation of PayPal and of your plugin for the exact screens. No product is recommended here.

Step 1: decide what kind of payment you take

Situation	Usual approach
Physical or digital products with a cart	An e-commerce plugin with a PayPal gateway (for WooCommerce, PayPal publishes its own official extension)
A single form: a booking deposit, an order, a registration fee, a donation	A form plugin with a PayPal add-on, or a dedicated payment-form plugin
Memberships or paid content with renewals	A membership plugin with PayPal subscription support
Fixed price, very low volume	A PayPal-hosted button or payment link pasted into a page, no plugin at all

A cart and coupons bring their own considerations; for WooCommerce shops, the article on WooCommerce coupons covers that side.

Step 2: evaluate the plugin

Whatever you choose, check these points in its documentation:

Which PayPal integration it uses. Current integrations use PayPal's REST APIs (Orders v2 for one-time payments, the Subscriptions API for recurring ones) and webhooks. Older plugins may rely on legacy "Payments Standard" buttons and IPN (Instant Payment Notification). Legacy flows still exist on many accounts, but new projects are better served by the REST-based ones.
Recurring support. Many form add-ons handle only one-time payments, or reserve subscriptions for a paid tier. Confirm it before you design a membership around it.
Where card data goes. Card fields should be rendered by PayPal (popup, redirect or hosted fields), so card numbers never touch your server. This keeps your PCI DSS scope small.
Webhook handling, refunds and logs. The plugin should record PayPal transaction IDs, show the payment status per entry and react to refunds and disputes.

Step 3: prepare PayPal and the sandbox

Use a PayPal business account; personal accounts are not meant for receiving payments on a website.
In the PayPal Developer Dashboard, PayPal provides sandbox accounts: a test business account (the seller) and a test personal account (the buyer). Sandbox payments use test money only.
Many plugins offer a "Connect with PayPal" onboarding button that links your account without copying keys. Others ask for the client ID and secret of a REST app created in the developer dashboard; there is one pair for sandbox and another for live.
Store the secret only in the plugin's settings or, better, in wp-config.php constants if the plugin supports them. Never paste it into a page, a form field or a public repository.

Step 4: build the form for one-time payments

A typical order or deposit form collects a name, an email, the item or option chosen and possibly a quantity. The payment field then calculates the total and sends the buyer to PayPal (or opens PayPal's popup). Points that matter:

Compute the price on the server. The amount must come from your configured products or rules, never from a hidden field the browser can edit. Good plugins recalculate the total on submission.
Show the currency and what is being paid for before the buyer leaves your site, and send a receipt by email afterwards.
Handle cancellations. Buyers who close the PayPal window should land back on a page that explains how to retry, and the entry should stay marked as unpaid.
Collect only the data you need and state in your privacy policy that payment is processed by PayPal.

Step 5: recurring payments

Subscriptions in PayPal's REST API are built from three objects: a product (what you sell), a plan (billing frequency, price, optional trial) and a subscription (one buyer's agreement to a plan). Plugins usually create the product and plan for you when you configure a recurring option in the form. When designing it:

State the amount, the billing interval and how to cancel next to the payment button. Consumer law in many countries requires clear renewal terms and an easy cancellation path.
Decide what happens when a renewal fails: PayPal retries according to the plan's settings, and your site should suspend access only once the subscription is actually suspended or cancelled.
Let members see their status on their account page.

Step 6: confirm payments with webhooks

The buyer's return to your "thank you" page is not proof of payment: the browser can be closed, or the URL visited directly. Deliver goods, accounts or access only when your server has been told by PayPal. With REST integrations, that is a webhook: PayPal sends an HTTPS POST to an endpoint on your site for events such as PAYMENT.CAPTURE.COMPLETED, PAYMENT.CAPTURE.REFUNDED, BILLING.SUBSCRIPTION.ACTIVATED or BILLING.SUBSCRIPTION.CANCELLED.

The plugin should verify each webhook's signature (PayPal provides a verification API for this) and ignore anything that fails.
It should check that the amount, currency and merchant on the event match the order it recorded.
Handlers must be idempotent: PayPal may deliver the same event more than once.
Check the webhook delivery history in the developer dashboard when something does not update.

Thinking of each payment as a record that moves through states (created, approved, completed, refunded) is the same model as in any CRUD application, and makes the logs much easier to read.

Step 7: test, then go live

In sandbox mode, run a successful payment, a cancelled one, a refund and, for subscriptions, an activation and a cancellation. Confirm that each one updates the form entry and sends the right emails.
Switch the plugin to live mode and replace sandbox credentials with live ones; this is the step most often forgotten.
Make one small real payment and refund it to confirm the live webhook works.
Keep caching plugins and security firewalls from blocking the webhook endpoint, and exclude checkout pages from page caching.

Security and maintenance checklist

HTTPS on the whole site.
WordPress core, theme and plugins kept up to date; remove unused payment plugins.
Administrator accounts protected with two-factor authentication.
Form inputs sanitised and validated server-side, as WordPress's plugin handbook describes.

Summary

Choose a plugin type that fits your use case and confirm that it uses PayPal's current REST APIs and supports recurring payments if you need them. Connect a business account, test every path in the sandbox, compute amounts on the server, confirm payments through verified webhooks rather than return pages, and switch carefully to live credentials. Follow PayPal's and the plugin's current documentation for the exact steps.

Sources

WordPress Developer Resources, Plugin Handbook: Sanitizing input.
PayPal Developer documentation: Orders v2 API, Subscriptions API, Webhooks and Sandbox testing guides.
PCI Security Standards Council, PCI DSS overview.