Dynamic Presentment (needs new title)

Overview

Dynamic presentment lets you show the Paze℠ button only to customers who are eligible to use Paze℠. Using the canCheckout() method, you can check whether an email address or mobile number is associated with a Paze wallet and then conditionally render the button. This helps reduce friction for eligible customers while keeping the checkout experience simple for everyone else. Please note that this capability currently exists within our Paze℠ Web SDK and not within the Paze℠ API.

At a high level, dynamic presentment involves:

• Capturing an email address or mobile number as the lookup key
• Calling canCheckout() to determine if there is a linked Paze wallet
• Rendering the Paze button only when the response field consumerPresent is true
• Falling back to your normal payment options when Paze is not available for a particular customer

When to use dynamic presentment

Use dynamic presentment when you want to prioritize showing the Paze button only to eligible customers, rather than displaying it to all customers by default.

Dynamic presentment is especially useful when:

• You want to avoid showing unavailable payment options to ineligible customers.
• You want to prioritize one primary payment button (for example, when screen space is limited).
• You want to conditionally promote Paze only when a wallet is confirmed to exist.
• You want to reduce visual clutter by rendering Paze only when it is relevant to the customer.

Note: Dynamic presentment is optional. If you cannot reliably capture an email or mobile number before showing payment options, use a static Paze button instead. Paze continues to work with a static button that’s always visible and uses the standard checkout() flow.

Integration Overview

The following steps describe how to implement the dynamic presentment of the Paze button.

1. Capture the lookup key and check eligibility

After initialize() completes and you have the customer’s emailAddress or mobileNumber, call canCheckout() to determine if a Paze wallet exists.

const paze = window.DIGITAL_WALLET_SDK;

async function checkPazeEligibility({ emailAddress, mobileNumber }) {
  try {
    const { consumerPresent } = await paze.canCheckout({
      emailAddress,
      mobileNumber, // mobileNumber takes precedence
    });

    return consumerPresent === true;
  } catch (error) {
    console.error("Paze canCheckout error", error);
    // Treat errors as not eligible and fall back to standard checkout
    return false;
  }
}

WHAT: This helper wraps canCheckout() and returns a simple boolean to drive UI.

WHY: Keeping this logic isolated makes it easier to reuse across product, cart, and checkout pages.

WHEN: Call this after you have a reliable email or mobile number (e.g., after a “Continue” or “Next” step).

BEST PRACTICES:

• Do not expose the raw error.message to consumers.
• Log error.reason for debugging and monitoring.
• Treat errors the same as consumerPresent === false and continue with your normal checkout options.

2. Render the Paze button conditionally

The Paze button container should be hidden by default and only displayed after eligibility is confirmed.

Simple DOM example:

<!-- Container for dynamic Paze button -->
<div id="paze-dynamic-container" hidden>
  <paze-button></paze-button>
</div>

async function renderPazeButtonIfEligible(emailAddress) {
  const isEligible = await checkPazeEligibility({ emailAddress });

  const container = document.getElementById("paze-dynamic-container");
  if (!container) return;

  container.hidden = !isEligible;
}

WHEN: Call renderPazeButtonIfEligible() after the customer submits an email or mobile number field (for example, after clicking “Continue” in your checkout form).

BEST PRACTICES:

• Keep at least one non-Paze payment option visible at all times.
• Avoid repeatedly calling canCheckout() for the same lookup key; cache the result per session where possible.

Note: Once the Paze button is rendered, checkout behavior is identical to other button-initiated integrations. See Express Pay Flow or Review & Pay Flow for checkout implementation details.

UX and error handling

• Ineligible (consumerPresent === false): Hide the Paze button and continue showing your normal payment options. Do not display an error message.
• Error from canCheckout(): Treat as “unknown” eligibility. Do not block checkout. Log the error and continue with your standard methods.
• Session changes: If the customer changes their email or mobile number, re-run canCheckout() to update the button state.
• Accessibility: Ensure that show/hide logic keeps focus behavior predictable, especially when the Paze button appears after form submission.