Payment Methods

The Revup Unified SDK multiple alternative payment methods through different payment providers

This page covers configurations for both Revup Unified SDK 1.0 and Revup Unified SDK 1.1.

Worldpay Payment Methods

RevUp supports some Worldpay-backed alternative payment methods: ideal, apple_pay, google_pay, and ideal.

SDK key	Method	Typical flow after submit
`apple_pay`	Apple Pay	Apple Pay overlay payment finalisation
`google_pay`	Google Pay	Google Pay overlay payment finalisation
`ideal`	iDEAL (Netherlands)	Bank redirect when required

How ideal renders

ideal is the one method whose appearance is decided per order, by two values your backend returns with it: which provider serves it, and whether the order is recurring. You do not choose either from the integration — you enable ideal once, and the SDK renders the matching shape.

Recurring order	What renders	Also dispatches
No	A one-click button — RevUp's own UI against your own backend, not routed through Stripe	-
Yes	An accordion row holding RevUp's own billing-address form — see The recurring form	`initialized`, `validation.changed` (`source: 'apm'`)

Whether it is a recurring order or not, an unrecognized provider — a typo, a renamed provider, a PSP never onboarded — fails closed on purpose. ideal is not rendered and the SDK dispatches apm.unavailable, collapsing the slot.

Ideal recurring form

A recurring ideal payment creates a mandate, and a mandate is created against the payer's billing address — so the native path collects one. The accordion body holds RevUp's own address form, in a sandboxed iframe on RevUp's domain, with its own Pay Now button.

Field	Required	Max length
State or province	No	50
Full name	Yes	70
Street address	Yes	100
City	Yes	50
Postal code	Yes	16
Country	Yes	56

Fields appear in that order, with city and postal code paired on one row and state and country on the next; a narrow container stacks them one per line. State or province is the only optional field — many countries, the Netherlands included, have no state in a postal address, so requiring it would block a valid payment. Every other field must be filled before Pay Now becomes active.

Prefill. When the order carries a payer address, the SDK fills these fields from it as the form renders — field by field, so values the order does not specify stay empty. It never overwrites what the payer has already typed, and every field stays editable: letting the payer correct the address before a mandate is created against it is the point of showing it. Only what the payer leaves in the fields is submitted; the prefill itself never is.

Ideal Events

This is the only ideal path that renders a form, so it is the only one that dispatches initialized and validation.changed — both with source: 'apm' and context.apm: 'ideal'. Their data.invalidFields keys are addressName, addressStreet, addressCity, addressState, addressPostcode and addressCountry.

Stripe Payment Methods

RevUp supports some Stripe-backed alternative payment methods through the Stripe Payment Element: They share the same checkout UX and event contract.

SDK key	Method	Typical flow after submit
`apple_pay`	Apple Pay	Apple Pay overlay payment finalisation
`google_pay`	Google Pay	Google Pay overlay payment finalisation
`pix`	PIX (Brazil)	QR code or bank UI inside Stripe; may require user interaction, amount must be in BRL
`ideal`	iDEAL (Netherlands)	Bank redirect when required
`sepa_debit`	SEPA Direct Debit	IBAN and mandate fields inside Stripe Element
`amazon_pay`	Amazon Pay	Payment confirmation inside Amazon overlay

Important: Use sepa_debit in your SDK configuration. Some backend APIs expose the alias sepa; the SDK maps that alias when calling the pay endpoint. Using name: 'sepa' in revup.init() is not valid and will cause initialization failure.
Regarding pix, the button will show only when amountinside the Order POST request is in BRL.

Enabling the methods

No new revup.init() fields are required. Enable a method when:

Your backend returns it as available for the order (with Stripe provider config including publicKey).
You list it in apms.primary, apms.secondary, or apms.other.

await revup.init({
  containerId: 'revup-container',
  apms: {
    secondary: [
      { name: 'pix' },
      { name: 'ideal' }
    ],
    other: [
      { name: 'sepa_debit' }
    ]
  }
});

type and color on ApmEntry are ignored for Payment Element methods (they apply to Express Checkout buttons only).

Checkout UX

Each method renders a collapsible Stripe Payment Element (accordion layout, starts collapsed).
A RevUp Pay Now submit button appears below the Element when expanded.
Only one payment section (card form or one Stripe method) is expanded at a time.
While a payment is processing, other payment slots are disabled automatically.
PIX, iDEAL, and SEPA logos appear in the “+ N more payment methods” toggle when placed in the other zone.

Backend prerequisites

Stripe publishable key (publicKey) in APM configuration.
Pay endpoint returns client_secret and return_url for Stripe confirmPayment.
Optional paymentMethodConfiguration for Stripe Payment Method Configuration.
Content Security Policy must allow https://js.stripe.com.

Events

Listen via revup.onRevupMessage(). See Log & Event Service for the full contract.

Event	When
`payment.submitted`	User clicked Pay Now; payment attempt started
`payment.action_required`	User must complete an step (QR, redirect, mandate). See payload below.
`payment.success`	Terminal success
`payment.failed`	Terminal failure — `error.name` is `pix_error`, `ideal_error`, or `sepa_debit_error`
`apm.unavailable`	Method cannot be used (config, SDK load, or capability)

payment.action_required payload (Stripe Payment Element):

context.apm — pix, ideal, or sepa_debit
context.transactionStatus — waiting_user_interaction
data.message — human-readable status (e.g. awaiting QR scan)

Note: payment.cancelled is not emitted for these methods. Users dismiss the flow by collapsing the accordion.

Appearance

RevUp partially themes the Stripe Payment Element by mapping Appearance API variables (border radius, font family, primary/background/text colors, accordion border, input focus). Full Appearance API rules do not apply to Stripe-hosted input fields.

Enabling Stripe Link

Include stripe_link in your APM configuration when calling init().

SDK 1.0

Add stripe_link to the apms.enabled array:

await revup.init({
  containerId: 'revup-container',
  apms: {
    enabled: ['apple_pay', 'google_pay', 'paypal', 'stripe_link'],
    buttonTypes: {
      apple_pay: 'plain',
      google_pay: 'plain',
      paypal: 'plain'
    }
  }
});

Supported APM values: 'apple_pay', 'google_pay', 'paypal', 'stripe_link'.

SDK 1.1

Place stripe_link in the appropriate zone (primary, secondary, or other):

await revup.init({
  containerId: 'revup-container',
  apms: {
    primary: [
      { name: 'apple_pay', capabilityDetection: true },
      { name: 'google_pay', capabilityDetection: true },
      { name: 'paypal', type: 'checkout', color: 'blue' }
    ],
    secondary: [
      { name: 'stripe_link' }
    ]
  }
});

info

Stripe Link does not support color customization in SDK 1.1 — the color property is ignored.

Checking availability

Before rendering Stripe Link, you can query which APMs are available for the current merchant session:

const paymentMethods = await revup.getApmsAvailable();
// e.g. ['apple_pay', 'google_pay', 'paypal', 'stripe_link', 'amazon_pay']

If Stripe Link is not returned, the method is not enabled for the merchant or order context.

Payment flow

Stripe Link payments follow the same indirect status flow as PayPal:

The SDK returns a WAITING_USER_INTERACTION status.
The customer completes authentication or confirmation in the Stripe Link UI.
A notification unlocks the payment to a final status (SUCCESS, FAILED, etc.).

This behavior is similar to 3D Secure card payments — the redirection URL is provided in the threeDSChallengeResult field.

Events

Stripe Link dispatches events with context.apm set to stripe_link. Key events include:

Event	Description
`validation.changed`	Fired when the Stripe Link element completeness changes (`data.complete` indicates whether the element is ready)
`payment.submitted`	Payment processing has started
`payment.action_required`	Customer interaction is required
`payment.success` / `payment.failed`	Terminal payment outcome
`payment.cancelled`	Customer cancelled the payment
`apm.unavailable`	Stripe Link could not be rendered (SDK load error or no available methods)
`stripe_link_error`	Stripe Link module encountered an error

For the full event reference, see Event Handling in the SDK 1.0 documentation.

Layout behavior (SDK 1.1)

In SDK 1.1, Stripe Link can be placed in any payment zone (primary, secondary, or other). If Stripe Link fails after initial render — for example, when the Stripe SDK loads but no saved methods are available — the SDK removes the method's slot and updates the layout automatically. No additional merchant handling is required; re-calling init() resets the layout.

See Checkout Layout for details on zone configuration and reactive layout behavior.

Worldpay Payment Methods​

How ideal renders​

Ideal recurring form​

Ideal Events​

Stripe Payment Methods​

Enabling the methods​

Checkout UX​

Backend prerequisites​

Events​

Appearance​

Enabling Stripe Link​

SDK 1.0​

SDK 1.1​

Checking availability​

Payment flow​

Events​

Layout behavior (SDK 1.1)​

Related documentation​

Worldpay Payment Methods

How ideal renders

Ideal recurring form

Ideal Events

Stripe Payment Methods

Enabling the methods

Checkout UX

Backend prerequisites

Events

Appearance

Enabling Stripe Link

SDK 1.0

SDK 1.1

Checking availability

Payment flow

Events

Layout behavior (SDK 1.1)

Related documentation