PCI Watch

Tracking changes across the Payment Card Industry

EMV® Agentic Payments - Framework for Specifications v1.0 DRAFT: Comment period ends 30-Sept 2026

v1.6 Draft Specification

Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidated Feedback Primary Contact Name: Working Group or Task Force: Secure Remote Commerce Working Group Document: EMV Secure Remote Commerce Specifications – API v1.6 DRAFT Date: September 2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Acknowledge, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 13-Aug-2026

of 6 EA Sections 2.1.31 + 2.2.2 Tables 2.31 + 2.63 Te In section 2.1.31, table 2.31, a new optional data element ‘dpaPublicKeyCredentials’ has been added to the definition of the ‘DpaData’ complex data object (with a very generic definition = “The public key of Public / Private key pair generated by DPA”). Also, in section 2.2.2, table 2.63, a new data element ‘vehiclePublicKeyCredentials’ is defined in the ‘DeviceSpecificationData for EVOP Use Case’ complex data object. The objectives / use cases of these new data elements are never explained (and their definition does not refer to FIDO2 passkeys) Note: as already stated on v1.5 DRAFT versions, it is very complicated to review/validate newly added data elements/values if we have no indication regarding their objective and use cases. Please clarify/confirm if the objective of the new ‘dpaPublicKeyCredentials’ data element is to permit implementing the specific use case ‘Passkey for Card Listing

  • Dynamic linking presentment’ which was presented during the EMV Tech Meeting of April 2026 (= on slide 6 of the EMV SRC Dedicated Technical Discussion slides)? And if yes, please provide some clarifications regarding the way to use this data element? And clarify if it may also be used for other use case (and which use cases)? And please clarify the use of the ‘vehiclePublicKeyCredentials’ added for the EVOP use case only (e.g. is the ‘vehiclePublicKeyCredentials’ for EVOP similar to the ‘dpaPublicKeyCredentials’ for Click To Pay)? Accept dpaPublicKeyCredentials is a generic data element that can be used by any DPA to provide its public key credentials when signing data. Its use is use-case specific. The description has been updated to reflect this. Please note that the only use case so far identified is the tolling use case. It is NOT required for the implementation of ‘Passkey for Card Listing
  • Dynamic linking presentment’. vehiclePublicKeyCredent ials can be used when a vehicle is signing data. The only use case so far identified is the tolling use case. Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidated Feedback Primary Contact Name: Working Group or Task Force: Secure Remote Commerce Working Group Document: EMV Secure Remote Commerce Specifications – API v1.6 DRAFT Date: September 2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Acknowledge, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 13-Aug-2026 of 6 EA 2.1.5 Table 2.5 Te In section 2.1.5, the definition of the data object type ‘AdditionalSource’ a third data element which may be used to identify an additional source has been added. In the Disposition of Comments on the SDK specification v1.5 DRAFT2, EMVCo had confirmed that AdditionalSource data object could be used both to obtain some additional Digital Cards to be listed in the Card List (using the ‘additionalSourceId’) or to obtain some additional information regarding some already obtained Cards and for which the merchant may need to obtain consent from the consumer (using the ‘uriData’). But there is not explanations regarding the use of the new ‘complianceSettings’ data element (even if it seems to be linked to the new ‘Consumer consent’ to validate ‘T&Cs’ It is not possible to validate the addition of this new data element if we do not have a minimal understanding of its use. Could you please clarify what are the use cases to be addressed ? And particularly: Do you confirm that the objectives of the updated AdditionalSource data object are: * to obtain some additional Digital Cards to be listed in the Card List (using the ‘additionalSourceId’); * to obtain some additional information (e.g. digital ID attributes) regarding some already obtained Cards and for which the merchant may need to obtain consent from the consumer (using the ‘uriData’); * to request the user to validate updated T&Cs (either during IDV or during Card Listing) ? And if not, please provide clarifications. Accept AdditionalSource data object carries the data between SRC System and the SRCi for the following: 1) as an indicator of additional cards available and its presentment 2) terms presentment data and captured results and 3) identifiers for SRC System to return additional cards from respective sources. Compliance settings may be used when additional terms need to be presented to and accepted by the consumer during a flow in which additional cards are retrieved. Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidated Feedback Primary Contact Name: Working Group or Task Force: Secure Remote Commerce Working Group Document: EMV Secure Remote Commerce Specifications – API v1.6 DRAFT Date: September 2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Acknowledge, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 13-Aug-2026 of 6 updates (as presented during April’s Tech. Meeting). EA Section 5.6.3 Table 5.6.11 Te In table 5.6.12 ‘Get Payload Definition – Response Body’, it seems that the definition of the signed data object ‘payloadResponse’ (of type JWS<CheckoutPayloadResponse>) should be updated to take into account the new data lists ‘encryptedPayloadList’ and ‘encryptedSignedPayloadList’ (which have been introduced in the definition of type ‘CheckoutPayloadResponse). Update the definition of the ‘payloadResponse’ data object to take into account the new data lists ‘encryptedPayloadList’ and ‘encryptedSignedPayloadList’. Or else, clearly indicate that and explain why the new lists cannot be used during a Get Payload operation. And if possible, please clarify when the Get Payload API is used instead of the Checkout API (as its use is never defined in the EMV SRC Use Case document). Accept The Get Payload API is designed to retrieve a single payload for each API call which is why the new lists cannot be used during a Get Payload operation. The description has been updated to clarify this. Consideration will be given in future API updates to expand the functionality of the Get Payload API to retrieve multiple payloads with a single API call. The use of Get Payload API is an implementation decision and as such describing when it can be used is not in scope for the API Specification. Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidated Feedback Primary Contact Name: Working Group or Task Force: Secure Remote Commerce Working Group Document: EMV Secure Remote Commerce Specifications – API v1.6 DRAFT Date: September 2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Acknowledge, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 13-Aug-2026 of 6 EA Section 5.8.4 Table 5.8.16 Te In table 5.8.16 ‘is Recognized Definition – Response Body’, the data element ‘recongnitionDomainName’ has been completely suppressed from the table (without indicating it as DEPRECATED). While this suppression has not been announced during EMV BoA or Tech Meeting. Please clarify why this data element is suppressed from the specification. Keep it listed in the table and indicate it as ‘DEPRECATED’ as other data elements when they are suppressed from the SRC specification. Accept Agreed and have adjusted to reflect that ‘recognitionDomainName’ is ‘DEPRECATED’. Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidated Feedback Primary Contact Name: Working Group or Task Force: Secure Remote Commerce Working Group Document: EMV Secure Remote Commerce Specifications – API v1.6 DRAFT Date: September 2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Acknowledge, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 13-Aug-2026 of 6 EA Sections 1.4.1 + 2.1.26 + 2.1.32 + 2.4.2 + 3.1.2 + 5.5.2 and 5.5.3 + A.1.1 Tables 2.26 + 2.32 + 2.73 + 3.2 ge A reference to the W3C SPC Standard has been added in section 1.4.1. + In tables 2.26 and 2.70, ‘identityType’ and ‘DeviceIdentityType’ have been renamed ‘identityAssuranceType’ and ‘DeviceIdentityAssuranceType’. + In table 2.32, the definition of ‘transactionAmount’ has been updated. + In table 2.73, the ‘Conditionality’ of ‘encryptedSignedPayload’ and ‘encryptedPayload’ have been updated. + In table 3.2, the definition of ‘signed_data’ has been updated. + In section 5.5, the definitions of the ‘Add Consumer Identities’ and ‘Unbind App Instance’ APIs have been clarified. + In Annex A.1.1, the list of ICS’Merchant Account Information IDs has been replaced by a generic sentence. But these updates are not listed in the Revision Log = Please, complete the Revision Log so that all significant updates are listed. And also, we recommend providing a version with Revision Marks when publishing a DRAFT for review (as is for EMV 3DS specifications). Accept Thank you for letting us know the revision marked version was not initially included. Your comment allowed us to attach it for the last part of the review. Many of the revisions listed were considered editorial, for instance, definition clarifications. A reference to the W3C SPC Standard has always been in the API specification. Previously it was mentioned in Section 2.2.1 and the failure to include it in Table 1.1 was an oversight which has now been corrected. We have also updated the revision log to reflect incorporation of the Bulletin for Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidated Feedback Primary Contact Name: Working Group or Task Force: Secure Remote Commerce Working Group Document: EMV Secure Remote Commerce Specifications – API v1.6 DRAFT Date: September 2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Acknowledge, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 13-Aug-2026 of 6 API v1.5, conditionality description referencing ‘encryptedSignedPayload’ and ‘encryptedPayload’, and updates to Annex A.1.1. EA Section 2.1.26 Table 2.26 ed In section 2.1.26, table 26, the identityProvider data element is now indicated as DEPRECATED (1st line) while it also seems to be kept in the table (2nd line). As this data element is not listed as suppressed in the Revision Log, it seems to us that the line indicating the data as DEPRECATED is an editorial error. Suppress 1st line of table 2.26. Accept The data element has been changed from Optional to Required. This was marked as DEPRECATED in error. This has now been corrected and the description updated.