Skip to main content

Payment methods

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

This page covers configurations for Revup Unified SDK 1.0, Revup Unified SDK 1.1, Revup Unified SDK 1.2 and Revup Unified SDK 1.3.

Worldpay payment methods​

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

SDK keyMethodTypical flow after submit
apple_payApple PayApple Pay overlay payment finalisation
google_payGoogle PayGoogle Pay overlay payment finalisation
idealiDEAL (Netherlands)Bank redirect when required

How iDEAL renders​

ideal is the one method whose appearance is decided per order, by the provider your backend returns with it. You do not choose it from the integration — you enable ideal once, and the SDK renders the matching shape. Whether the order is recurring makes no difference: from SDK 1.2.13 the native shape is the one-click button in both cases.

providerWhat rendersAlso dispatches
stripeStripe Payment Element accordion row — see Stripe payment methods—
worldpay, or no provider at allA one-click button — RevUp's own UI against your own backend, not routed through Stripe. The same button whether or not the order is recurring—
any other non-empty valueNothing: ideal is not rendered and the SDK dispatches apm.unavailable, collapsing the slotapm.unavailable

An unrecognized provider — a typo, a renamed provider, a PSP never onboarded — fails closed on purpose. ideal served natively and ideal served through Stripe pay through different rails, so the SDK will not guess a rail from a value it cannot interpret.

Recurring iDEAL​

A recurring iDEAL payment is processed as a SEPA Direct Debit, whose billing address is optional, so the SDK does not ask the payer for one. Since SDK 1.2.13 the billing-address form that SDK 1.2.3 introduced for recurring orders is gone: recurring and non-recurring orders render the same one-click button.

Colours​

The native one-click button accepts color: 'white' | 'dark' — a first-party style rather than a vendor preset. It is honoured only when ideal is served natively and ignored on the Stripe-served path. An unrecognized value logs a warning and falls back to white.

Native ideal defaults to white in every zone, primary included, because its button carries a fixed magenta iDEAL mark designed for a light surface. Set color: 'dark' explicitly if you want the accent treatment.

iDEAL events​

Whichever way ideal is served, its events carry source: 'apm' and context.apm: 'ideal', like every other APM.

On the native path:

  • payment.cancelled is dispatched when the payment is cancelled.
  • payment.action_required is dispatched when the backend reports waiting_user_interaction / in_process, or returns a URL to redirect to (iDEAL's issuer selection). In that case data.action may be present, and the SDK acts on it itself — no merchant handling is required.
  • initialized and validation.changed are not dispatched. They belonged to the recurring billing-address form removed in SDK 1.2.13; if you were reading them for ideal, they no longer fire.

For the full event contract, see Event contract in the SDK 1.3 documentation.

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 keyMethodTypical flow after submit
apple_payApple PayApple Pay overlay payment finalisation
google_payGoogle PayGoogle Pay overlay payment finalisation
pixPIX (Brazil)QR code or bank UI inside Stripe; may require user interaction, amount must be in BRL
idealiDEAL (Netherlands)Bank redirect when required
sepa_debitSEPA Direct DebitIBAN and mandate fields inside Stripe Element
amazon_payAmazon PayPayment confirmation inside Amazon overlay
klarnaKlarnaRedirect to the provider's own page to authorise the payment, then back to the return URL (from SDK 1.2.15)
affirmAffirmRedirect to the provider's own page to authorise the payment, then back to the return URL (from SDK 1.2.15)
bizumBizumRedirect to the provider's own page to authorise the payment, then back to the return URL (from SDK 1.2.15)

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.

klarna, affirm and bizum are available from SDK 1.2.15. Like sepa_debit and pix, they render as inline Stripe Payment Element accordion rows and are always Stripe-served — they have no native variant. Because the payer authorises on the provider's own page, the last event you receive may be payment.submitted or payment.action_required: always confirm the outcome server-side.

Important: Bizum supports one-off payments only

Please note that Bizum can only be used to process one-off (single) payments. Recurring payments and subscriptions are not supported through this payment method.

If you offer recurring billing, please ensure that you select an alternative payment method that supports recurring transactions.

PayPal (direct connection)​

Note: PayPal Configuration requires prior Company Onboarding with Paypal. Please contact our Tech Support team so they can create the RevUp MID and provide you with the PayPal Onboarding link to complete the procedure. As long as the Onboarding is not completed with a SUCCESS status, a MID cannot be issued.

Payment flow​

Paypal payments follow the same indirect status flow as Stripe_link:

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

This behavior is as well similar to 3D Secure card payments

Enabling the methods​

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

  1. Your backend returns it as available for the order (with Stripe provider config including publicKey).
  2. 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' },
      { name: 'klarna' },
      { name: 'affirm' },
      { name: 'bizum' }
    ]
  }
});

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.

EventWhen
payment.submittedUser clicked Pay Now; payment attempt started
payment.action_requiredUser must complete an step (QR, redirect, mandate). See payload below.
payment.successTerminal success
payment.failedTerminal failure — error.name is pix_error, ideal_error, sepa_debit_error, klarna_error, affirm_error or bizum_error
apm.unavailableMethod cannot be used (config, SDK load, or capability)

payment.action_required payload (Stripe Payment Element):

  • context.apm — pix, ideal, sepa_debit, klarna, affirm or bizum
  • 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.

context.transactionStatus (from SDK 1.2.15): on every Stripe-served method it is always 'success' on payment.success and is also set — to 'failed' — on payment.failed. The value is the SDK's own reading of the outcome ('waiting_user_interaction', 'success' or 'failed'), never Stripe's raw status.

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.

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:

  1. The SDK returns a WAITING_USER_INTERACTION status.
  2. The customer completes authentication or confirmation in the Stripe Link UI.
  3. 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:

EventDescription
validation.changedFired when the Stripe Link element completeness changes (data.complete indicates whether the element is ready)
payment.submittedPayment processing has started
payment.action_requiredCustomer interaction is required
payment.success / payment.failedTerminal payment outcome
payment.cancelledCustomer cancelled the payment
apm.unavailableStripe Link could not be rendered (SDK load error or no available methods)
stripe_link_errorStripe 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.