Payment CCAvenue Module — Storefront | Supercommerce by SuperLabs

The customer-side verify endpoint called after CCAvenue returns the shopper, from web and the Flutter SDK alike. The body is optional — the server reads CCAvenue's Status API rather than trusting the client's callback.

The customer-side verify endpoint, called after CCAvenue hands the shopper back — from web checkout and from the Flutter SDK alike. The body is optional, because neither callback is trustworthy: a browser can rewrite the posted form, and an app can substitute the SDK's encResponse. The server reads CCAvenue's Status API itself and reconciles from that.

Source: api-modules/payment-ccavenue/src/controllers/store-ccavenue-verify.controller.ts.

CCAvenue is one of several payment providers. Configuration, the place-order integration and refunds live in common/payment-ccavenue; the return and notification surfaces are in webhooks/payment-ccavenue. This file documents the customer-callable endpoint only.

`POST /store/orders/:id/ccavenue/verify`

Settles a CCAvenue payment for the caller's own order.

Auth: customer session (BetterAuthGuard).

Path parameters

Name	Description
`id`	Internal order id (UUID), as returned by place-order.

Body

Optional.

{
  "encResponse": "7f44b71d6849f488…"   // optional — from the Flutter SDK
}

Field	Type	Notes
`encResponse`	string, ≤ 20000 chars	What `CCAvenueSDK().initTransaction()` returns in `data.encResponse`. Logged for diagnostics only. Never used to settle the order. Web callers send no body at all.

Response

200 with the order in the standard envelope, after the transition is applied.

{
  "data": { "id": "…", "status": "confirmed", "paymentStatus": "paid", "…": "…" },
  "message": "Success",
  "statusCode": 200
}

Errors

Status	`errorCode`	When
`404`	—	Order does not exist, or belongs to another customer. Cross-customer ids return 404, never 403.
`400`	—	Order was not placed via the CCAvenue provider.
`400`	—	CCAvenue's captured amount does not match the order total, or the callback does not match the order's place-time record.
`409`	`PAYMENT_NOT_YET_CAPTURED`	CCAvenue still reports a non-terminal status (`Initiated`, `Awaited`). Retry shortly.

Behaviour

Idempotent. If the notification webhook already settled the order, the current order is returned unchanged rather than erroring.
Terminal failures are applied, not just reported. A CCAvenue status of Aborted, Cancelled, Unsuccessful and friends cancels the order through the same path a webhook would take, releasing inventory.
409 means wait, not fail. Poll a few times before giving up; a shopper on a slow bank redirect can legitimately sit in Awaited for a few seconds.

Client flow

Web

Place the order with paymentProvider: "ccavenue".
Navigate the browser to clientPayload.redirectUrl. That endpoint performs the form POST CCAvenue requires, so no gateway-specific client code is needed.
CCAvenue returns the shopper to the API's return handler, which settles the order and 302s to the storefront with ?order=&status=.
On landing, call this endpoint to confirm — it is idempotent, so it is safe even when the return handler already did the work.

Flutter

Place the order with the APP platform.
Pass the returned payload straight into CCAvenueOrder and call CCAvenueSDK().initTransaction(order).
Call this endpoint, optionally forwarding data.encResponse.
Render from the returned order's paymentStatus, not from the SDK's orderStatus.

Always render the outcome from this endpoint's response. The SDK's own orderStatus reflects what CCAvenue told the device, which is not what the server has verified and committed.

Payment CCAvenue Module — Storefront

On this page