Checking access…

Skip to main content
Version: v2

V1 to V2 Capability Parity Matrix

Use this matrix during migration planning to confirm whether each V1 capability is already supported in V2, changed in V2, deferred for a later phase, or unsupported in the current rollout.

Merchant-safe availability statement

Last validated: 2026-08-26
Accountable owners: CCG Product and API owners

V2 is available in production. Availability is operation-specific. Before migration, confirm that every operation in scope is production-ready and enabled for the merchant. Deferred operations and operations not listed in the environment matrix are not merchant-ready.

Status meanings

StatusMeaning
SupportedThe capability is available for merchant use in the relevant V2 flow.
ChangedThe capability exists in V2, but the contract, payload shape, scope, or operational model changed.
DeferredThe capability is planned or partially published, but is not merchant-ready for the current rollout phase.
UnsupportedNo approved V2 path is currently available for the migration phase in scope.

Capability matrix

AreaCapabilityV1 operationV2 operationV2 readinessContract statusCross-version supportEnvironment availabilityMerchant actionSource
PaymentsCreatePOST /paymentsPOST /v2/paymentsChangedPublished; allocation-based request and responseCreates V2-native resources onlyProduction-ready when enabled for the merchant; stage requires separate confirmationUpdate request construction and allocation parsingOpenAPI
PaymentsRetrieve by IDGET /payments/{paymentId}GET /v2/payments/{paymentId}ChangedPublished; V2 {url, data} envelopeEligible V1-origin payments when compatibility is enabled; otherwise normally 404Production-ready when compatibility is enabled for the merchant; stage requires separate confirmationEnable compatibility and use the V2 parserBackward compatibility
PaymentsSearch by merchant transaction IDGET /payments?merchantTransactionId={id}GET /v2/payments?merchantTransactionId={id}ChangedPublished; V2 response shapeValidate V1-origin search with compatibility enabledProduction-ready when compatibility is enabled for the merchant; stage requires separate confirmationUpdate parsing and verify merchant-scoped lookup behaviorOpenAPI
PaymentsCapturePATCH /payments/{paymentId}/capturePATCH /v2/payments/{paymentId}/captureChangedPublished; allocation-aware responseEligible V1-origin payments when compatibility is enabledProduction-ready when enabled for the merchant; stage requires separate confirmationVerify eligible states and V1 webhook handlingEnvironment availability
PaymentsCancelPATCH /payments/{paymentId}/cancelPATCH /v2/payments/{paymentId}/cancelChangedPublished; V2 cancellation contractEligible V1-origin payments when compatibility is enabledProduction-ready when enabled for the merchant; stage requires separate confirmationVerify eligible states and V1 webhook handlingEnvironment availability
RefundsCreatePOST /refundsPOST /v2/refundsChangedPublished; allocation-based response and unique refund IDSupported for eligible V1-origin payments when compatibility is enabledProduction-ready when enabled for the merchant; stage requires separate confirmationApply full or partial linked-refund construction rulesOpenAPI
RefundsRetrieve by IDGET /refunds/{refundId}GET /v2/refunds/{refundId}ChangedPublished; refundAllocations[] responseEligible V1-origin refunds when compatibility is enabledProduction-ready when enabled for the merchant; stage requires separate confirmationUpdate parser and poll by parent refundIdOpenAPI
SessionsCreatePOST /sessionsPOST /v2/sessionsChangedPublished; revised session requestNo cross-version bridge; migrate flow by flowProduction-ready when enabled for the merchant; stage requires separate confirmationUpdate request fields and session modesSession comparison
SessionsRetrieve by IDGET /sessions/{sessionId}GET /v2/sessions/{sessionId}ChangedPublished; revised responseNo cross-version bridge; migrate flow by flowProduction-ready when enabled for the merchant; stage requires separate confirmationUpdate response parsingSession comparison
Checkout sessionsRetrieveGET /checkout-sessions/{sessionId}GET /v2/checkout-sessions/{sessionId}ChangedPublished retrieval contractUse when enabled for the merchantProduction-ready when enabled for the merchant; stage requires separate confirmationUpdate response parsing and validate session state handlingEnvironment availability
Checkout sessionsUpdatePATCH /checkout-sessions/{sessionId}PATCH /v2/checkout-sessions/{sessionId}ChangedPublished operation-based update contractUse when enabled for the merchantProduction-ready when enabled for the merchant; stage requires separate confirmationUpdate request construction and response handlingUpdate comparison
Checkout sessionsCancelPATCH /checkout-sessions/{sessionId}/cancelPATCH /v2/checkout-sessions/{sessionId}/cancelChangedPublished cancellation contractUse for eligible sessions when enabled for the merchantProduction-ready when enabled for the merchant; stage requires separate confirmationValidate session state and cancellation responseCancel comparison
Checkout sessionsCreate child sessionPOST /checkout-sessions/{sessionId}/child-sessionsPOST /v2/checkout-sessions/{sessionId}/child-sessionsChangedPublished child-session contractUse when parent-session and child-session rules are satisfiedProduction-ready when enabled for the merchant; stage requires separate confirmationValidate parent state, child-session rules, and response handlingChild-session comparison
Payment methodsRetrieve by IDGET /payment-methods/{payment-method-id}GET /v2/payment-methods/{id}ChangedPublished; revised wallet responseNo blanket cross-version commitmentProduction readiness unconfirmedValidate the flow and environment before migrationOpenAPI
Payment methodsUpdatePATCH /payment-methods/{payment-method-id}PATCH /v2/payment-methods/{id}ChangedPublished; revised request and responseNo blanket cross-version commitmentProduction readiness unconfirmedValidate IDs, scope, and contract per flowOpenAPI
Payment methodsDeleteDELETE /payment-methods/{payment-method-id}DELETE /v2/payment-methods/{id}ChangedPublished; revised wallet contractNo blanket cross-version commitmentProduction readiness unconfirmedValidate IDs, scope, and contract per flowOpenAPI
Payment methodsSearchPOST /payment-methods/searchPOST /v2/payment-methods/searchChangedPublished; revised search contractNo blanket cross-version commitmentProduction readiness unconfirmedValidate identity inputs and response shapeOpenAPI
Token flowsCreate paymentPOST /token/paymentsPOST /v2/token/paymentsChangedPublished; revised PCI payment contractNo blanket cross-version commitmentProduction readiness unconfirmedUpdate payload and use the environment-specific PCI scopeOpenAPI
Token flowsSet up payment methodPOST /token/setup-payment-methodsPOST /v2/token/setup-payment-methodsChangedPublished; revised setup contractNo blanket cross-version commitmentProduction readiness unconfirmedUpdate payload and use the environment-specific PCI scopeOpenAPI
Token flowsRetrieve setup statusGET /token/setup-payment-methods/{setupPaymentMethodId}GET /v2/token/setup-payment-methods/{setupPaymentMethodId}ChangedPublished; revised responseNo blanket cross-version commitmentProduction readiness unconfirmedUpdate response parsingOpenAPI
WebhooksPayment eventsV1 payment webhookV2 payment webhookChangedPublished; V2 allocation payloadV1-origin payment actions can emit V1 payment webhooks during parallel useAvailable only when the corresponding operation and environment are availableParse both versions and deduplicate eventsPayment comparison
WebhooksRefund eventsV1 refund webhookV2 refund webhookChangedPublished; V2 allocation payloadRefunds created through V2 emit V2 refund webhooksAvailable only when refund creation is availableParse both versions and deduplicate eventsRefund comparison
3DSConfirm payment allocationNo merchant-facing V1 equivalentPATCH /v2/payments/{paymentId}/allocations/{allocationId}/confirmChangedPublished user-scoped operationApplies to V2 payment allocations; not a merchant-backend recovery callProduction readiness unconfirmedLet the customer-facing checkout flow call it with user scope3DS confirmation

How to use this matrix

  1. List every V1 flow in the current integration.
  2. Match each flow to an operation row and record its Supported, Changed, Deferred, or Unsupported readiness.
  3. For every Changed row, validate the exact request, response, webhook, and status behavior in the linked source pages.
  4. Treat “not listed in the environment matrix” as unconfirmed, not available.
  5. Do not schedule cutover for Deferred or Unsupported operations without an approved exception or alternate path.