Proposal: Extending Payment Confirmation experience to include line items

[vthub]

Currently, Secure Payment Confirmation (SPC) is designed to streamline authentication during a payment transaction and to produce cryptographic evidence that the user has confirmed transaction details. The specification ensures that critical payment information, such as the payeeName, payeeOrigin, and total amount, is presented to the user and subsequently included in the CollectedClientData dictionary, which cannot be tampered with via JavaScript. This provides a strong foundation for confirming user consent to a payment.

To enhance dispute protection, particularly against "friendly fraud," and to more explicitly confirm the buyer's intent to purchase specific items, I would like to explore the inclusion of detailed order information. This would provide payment networks with incontrovertible cryptographic evidence that the buyer confirmed the specific products or services displayed to them, going beyond just the total amount. This aligns with the goal of SPC to reduce authentication friction yet decrease fraud during checkout by making the confirmed transaction details more comprehensive and transparent.

Use Cases

This enhancement would be particularly beneficial for:

• One-click checkouts. In scenarios where user interaction is minimal, presenting a clear, cryptographically linked summary of the items being purchased directly within the SPC UX would provide a strong record of buyer intent, reducing ambiguity and potential for disputes.
• Agentic checkouts. When product selection is performed on behalf of the buyer, the ability for the user to confirm a detailed list of items via SPC directly addresses the need for transparency and explicit consent for the entire order.

Proposed Modifications

To integrate order information, modifications would be required across the

1. SecurePaymentConfirmationRequest dictionary (for the request),
2. AuthenticationExtensionsPaymentInputs and CollectedClientAdditionalPaymentData dictionaries (for cryptographic linking), and
3. Transaction confirmation UX (for display).

Payment Confirmation Request changes

A new optional member, such as lineItems, should be added to the SecurePaymentConfirmationRequest dictionary. This member would be a sequence of dictionaries, each representing a single product or service being purchased.

Payment Inputs and Payment Data changes

For the lineItems to be cryptographically linked to the authentication assertion, they must be included in the AuthenticationExtensionsPaymentInputs dictionary. This ensures that the order details are passed as part of the payment-specific data.

Consequently, lineItems would also need to be a member of the CollectedClientAdditionalPaymentData dictionary. This crucial step ensures that the order information is signed along with other transaction details and returned to the Relying Party for verification, providing the necessary cryptographic evidence of user intent.

Display in Transaction Confirmation UX

The user interface presented to the user for transaction confirmation currently includes the payeeName, payeeOrigin, total, instrument details, and payment entities logos. The lineItems must be prominently displayed within this user interface, providing the user with a clear, receipt-like summary of the items they are consenting to purchase.

While the specification intentionally does not require a User Agent to display a particular user interface to preserve implementation choice, similar to the non-normative UX guidelines for payeeName and payeeOrigin, recommendations could be developed for lineItems.

These guidelines would focus on:

• Clarity and readability. Ensuring each line item is presented clearly, with itemName and quantity easily discernible.
• Consistency across platforms. Providing guidance for displaying line items effectively on different screen sizes, such as mobile and desktop, while maintaining a consistent user experience.
• Truncation strategies. Offering best practices for truncating long itemName or description strings to fit available screen space, without losing critical information, akin to how payeeName and payeeOrigin are handled.

Verification by Relying Party

When a Relying Party receives the PublicKeyCredential returned from a successful SPC invocation, it already performs a series of verification steps. This process would be extended to include the lineItems too.

[ianbjacobs]

As part of the discussion, we should look at the relationship between lineItems and paymentItem in Payment Request

[tblachowicz]

I concur with @ianbjacobs assessment. The PaymentDetialsInit and PaymentDetialsBase that already can be used to pass line items to RP API. However I don't think current SPC implementations actually render the data on the payment sheet, there it is a matter not only for PR, but also SPC.

[stephenmcgruer]

We (partially, I would say?) discussed this issue at the Web Payments Working Group session (minutes) at TPAC 2025. Main points that I heard:

• There is interest in this primarily for agentic checkouts, to confirm things such as the 'cart mandate' described in protocols like AP2.
• However there was negative feedback from some (NickTR, JohnB) that SPC should be kept to just the payments, and that trying to include line items in signed data has been tried before and is troublesome from various perspectives.

Overall, no significant takeaways to either commit or not commit to the issue from the group. It likely requires further discussion at some point in the future. It also did not come up at all in the prioritization discussion, which may indicate low priority for folks currently testing SPC.

[tblachowicz]

Isn't that as straightforward as supporting in SPC displayItems element in PaymentDetails as defined in Payment Request API?

const details = {
  id: "", //Identifier of the cart / order
  displayItems: [
    {
      label: "Fancy Cowboy Hat", // Line item #1
      amount: { currency: "GBP", value: "50.00" },
    },
    {
      label: "Snake Creek Western Boots", // Line itme #2
      amount: { currency: "GBP", value: "200.00" },
    },
    {
      label: "Buffalo Skull Belt", // Line itme #3
      amount: { currency: "GBP", value: "30.00" },
    },
  ],
  total: {
    label: "Total amount incl. tax",
    amount: { currency: "GBP", value: "280.00" },
  },
};

To satisfy @vthub requirements we could add quantity attribute to PaymentItem dictionary. But this is separate point, IMO.

As far as I can tell, SPC implementation currently only can handle total attribute of PaymentDetails. @stephenmcgruer, Could that be changed to support the cart/order line items to be both displayed on payment sheet and included in the signed client data?

[stephenmcgruer]

As far as I can tell, SPC implementation currently only can handle total attribute of PaymentDetails. @stephenmcgruer, Could that be changed to support the cart/order line items to be both displayed on payment sheet and included in the signed client data?

This is correct - the specification cost is minor here. The bigger question is whether implementers (hi!) would be ok supporting the necessary UX to embed line items, from both a product/UX and web-security perspective. I think that's a good open question for 2026, and will include it in our planning discussions :)

[vthub]

I agree. The right place to build this is on top of Payment Request, not as SPC-specific logic. Payment Request already models line items and totals, and SPC should stay focused on confirmation and signing, not cart semantics.

From a priority standpoint, I would prefer to see broader SPC adoption first. Getting consistent support and usage across browsers and platforms feels more important than extending the signed payload in v0.

This feels like a reasonable follow-on once SPC is widely deployed and we have more real-world feedback on UX and security.