V2 API Environment Availability
This page describes which V2 endpoints are available in each CCG environment and what status codes to expect when an operation is not available.
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 or stubbed operations must not be used.
Environment Access Matrix
| Environment | V2 Endpoints Available | Behaviour |
|---|---|---|
dev | ✅ Yes | All implemented endpoints accessible; stubs return 501 |
test | ✅ Yes | All implemented endpoints accessible; stubs return 501 |
reg | ✅ Yes | All implemented endpoints accessible; stubs return 501 |
perf | ✅ Yes | All implemented endpoints accessible; stubs return 501 |
stage | Confirm per operation | Stage readiness is validated separately; do not infer it from production availability |
prod | ✅ Operation-specific | Supported operations are available when enabled for the merchant; deferred and unconfirmed operations must not be used |
Production availability for one V2 operation does not establish availability for another. Confirm operation readiness, merchant enablement, credentials, routing, and rollback ownership before sending production traffic.
Response Codes
503 — Service Unavailable
An unavailable route or service can return 503 Service Unavailable:
{
"status": 503,
"title": "V2_ENDPOINT_UNAVAILABLE",
"detail": "The requested service is currently unavailable."
}
Do not interpret a 503 from one operation as a blanket status for all V2 routes. Confirm the affected operation and environment with CCG support.
Endpoint Status Reference
Payment Service (wallet-payment-service)
| Endpoint | Method | Status | Notes |
|---|---|---|---|
/v2/payments | POST | ✅ Implemented | Create split-tender payment |
/v2/payments | GET | ✅ Implemented | Get payment by merchantTransactionId |
/v2/payments/{id} | GET | ✅ Implemented | Get payment by paymentId |
/v2/payments/{id}/capture | PATCH | ✅ Implemented | Capture authorized payment |
/v2/payments/{id}/cancel | PATCH | ✅ Implemented | Cancel eligible payment |
/v2/refunds | POST | ✅ Implemented | Create refund |
/v2/refunds/{refundId} | GET | ✅ Implemented | Get refund status |
Auth Service (wallet-auth-service)
| Endpoint | Method | Status | Notes |
|---|---|---|---|
/v2/sessions | POST | ✅ Implemented | Create checkout session |
/v2/sessions/{id} | GET | ✅ Implemented | Get session status |
/v2/checkout-sessions/{id} | GET | ✅ Implemented | Production-ready when enabled for the merchant; validate response handling |
/v2/checkout-sessions/{id}/cancel | PATCH | ✅ Implemented | Production-ready when enabled for the merchant; validate eligible session state |
/v2/checkout-sessions/{id}/child-sessions | POST | ✅ Implemented | Production-ready when enabled for the merchant; validate parent-session state and child-session rules |
/v2/checkout-sessions/{id} | PATCH | ✅ Implemented | Production-ready when enabled for the merchant; validate update operation and response handling |
How It Works
Routing and operation readiness are evaluated independently:
Incoming /v2/ request
│
▼
┌───────────────────────────────────────────────────────────┐
│ Layer 1: Istio VirtualService (gateway) │
│ Match public path and route to the owning service │
└───────────────────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────┐
│ Layer 2: Merchant and operation readiness │
│ Confirm environment availability and merchant enablement │
└───────────────────────────────────────────────────────────┘
│ (enabled operations)
▼
┌───────────────────────────────────────────────────────────┐
│ Layer 3: V2NotImplementedFilter │
│ Handler annotated @V2NotImplemented → 501 JSON response │
│ Handler not annotated → pass through │
└───────────────────────────────────────────────────────────┘
│ (implemented endpoints only)
▼
Controller handler executes normally
Production routing does not override operation-level controls. A route can exist while its operation remains deferred or unavailable to a merchant.
Infrastructure Routing
V2 public paths are routed through the CCG API v2 VirtualService (ccg-api-v2). All CCG V2 endpoints are exposed via Istio VirtualService — there is no direct HCP ingress for any of these paths. The Istio IngressGateway (istio-ingressgateway) sits at the cluster edge and forwards traffic to the appropriate service via the VirtualService route rules.
| Method | Public path | Rewrites to | Service | Routing |
|---|---|---|---|---|
POST | /payments | /v2/payments | payment-service | Virtual (Istio) |
GET | /payments | /v2/payments | payment-service | Virtual (Istio) |
POST | /token/payments | /v2/payments | payment-service (PCI) | Virtual (Istio) |
PATCH | /payments/{id}/cancel | /v2/payments/{id}/cancel | payment-service | Virtual (Istio) |
PATCH | /payments/{id}/capture | /v2/payments/{id}/capture | payment-service | Virtual (Istio) |
POST | /refunds | /v2/refunds | payment-service | Virtual (Istio) |
GET | /refunds/{refundId} | /v2/refunds/{refundId} | payment-service | Virtual (Istio) |
POST | /sessions | /v2/sessions | auth-service | Virtual (Istio) |
GET | /sessions/{sessionId} | /v2/sessions/{sessionId} | auth-service | Virtual (Istio) |
GET | /checkout-sessions/{id} | /v2/checkout-sessions/{id} | auth-service | Virtual (Istio) |
PATCH | /checkout-sessions/{id}/cancel | /v2/checkout-sessions/{id}/cancel | auth-service | Virtual (Istio) |
POST | /checkout-sessions/{id}/child-sessions | /v2/checkout-sessions/{id}/child-sessions | auth-service | Virtual (Istio) |
PATCH | /checkout-sessions/{id} | /v2/checkout-sessions/{id} | auth-service | Virtual (Istio) |
Production routes are forwarded to the owning service for operations that are production-ready and enabled for the merchant. Stage availability must be confirmed independently. The presence of a route does not make a deferred operation available.