REST API

Every Payment Page route lives in the payment-page/v1 namespace, so the full URL is /wp-json/payment-page/v1/<route>.

Access rules#

Admin routes#

Dashboard and form builder#

Payment gateways#

Elementor install#

Both routes accept only identifier=elementor. They let Quick Setup install Elementor and are not a general plugin installer.

Feature updates#

Checkout routes (signed checkout)#

The payment form calls these in order: sync the payment details, create the provider payment, then complete it.

Every Stripe and PayPal route above (except /payment/status) allows 6 calls per minute per payment and 24 per minute per IP address. Requests over the limit get HTTP 429.

On the Free plan, Stripe payments are created on your connected account through the Payment Page API (api.paymentpageplugin.com), which adds the 2% Payment Page platform fee. With Pro, Payment Page creates them directly with Stripe.

Upsell charge#

POST /stripe/upsell-charge charges the offer configured on the form to the same customer and card as the original payment. It works only for a completed one-time card payment, and each offer can be charged once per original payment.

Responses:

• {"status": "ok"} when the charge succeeded or is processing.
• {"requires_action": true, "payment_intent_id": "...", "payment_intent_secret": "..."} when the card needs authentication. The form completes it with Stripe.js, then calls the route again with finalize_payment_intent_id.

Payment status#

POST /payment/status reports where a payment attempt stands. It never creates, confirms or changes anything.

Required parameters: post_id, payment_gateway, payment_method, payment_id, payment_secret, checkout_token, price_amount.

{
  "payment_id": 123,
  "status": "processing",
  "provider_status": "processing"
}

For an unpaid Stripe payment, Payment Page reads the bound PaymentIntent from Stripe at most once every 10 seconds per payment. provider_status is that raw PaymentIntent status, or empty when there is none.

Form routes (signed checkout and open)#

Webhook routes#

{mode} is live or test.

Payment Page acts on these Stripe events and acknowledges any other event without acting on it:

• payment_intent.succeeded, payment_intent.payment_failed, payment_intent.processing, payment_intent.canceled
• setup_intent.succeeded, setup_intent.setup_failed, setup_intent.canceled
• invoice.paid, invoice.payment_failed
• customer.subscription.created, customer.subscription.updated, customer.subscription.deleted

An event must also carry the payment ID and site domain that Payment Page attached to the Stripe object. Each event is processed once, even when Stripe delivers it again.

When you connect Stripe, Payment Page creates its own webhook endpoint for that mode with these events and saves the signing secret. Setup details: Stripe Webhook Configuration and PayPal Webhook Configuration.

Calling a route from PHP#

The standard WordPress REST helpers work. Admin routes need a current user with payment_page_settings.

$request  = new WP_REST_Request( 'GET', '/payment-page/v1/administration/dashboard' );
$response = rest_do_request( $request );
$data     = $response->get_data();

Plugin constants#

Defined in payment-page.php and lib/definitions.php:

if ( current_user_can( PAYMENT_PAGE_ADMIN_CAP ) ) {
    // Runs only for users who can manage Payment Page.
}

Need help with an integration? Contact support.