Payment CCAvenue — Admin | Supercommerce by SuperLabs

How an operator configures, enables and refunds through CCAvenue, including the MARS panel checklist, the IP allowlist requirement, and the Instant Gratification assumption this integration depends on.

How an operator sets CCAvenue up and operates it.

CCAvenue deliberately adds no admin HTTP endpoints of its own. Configuration goes through the generic settings registry, and refunds go through the provider-neutral routes on admin/orders. This page is the operator's map of those existing surfaces; there is no CCAvenue-specific admin API to document.

Configuration

Admin → Plugins → CCAvenue → Configuration, backed by the payment.ccavenue settings group. Gated on adminSetting:read to view and adminSetting:update to save — the same permissions as every other plugin.

Credentials come from the CCAvenue MARS panel under Settings → API Keys: merchant id, access code and working key. Values are read on every payment, verification and notification, so rotating one takes effect immediately without a deploy.

The full key reference lives in the provider overview. The overview page in the admin shows at a glance whether the provider is configured, which environment it points at, and whether refunds are on.

MARS panel checklist

Three things must be done in the CCAvenue panel. The configuration page renders the first with copy buttons.

1. Register the return URLs

{api_base}/webhooks/payments/ccavenue/response   → redirect URL
{api_base}/webhooks/payments/ccavenue/cancel     → cancel URL
{api_base}/webhooks/payments/ccavenue/notify     → dynamic event notification

The notification URL is what settles an order when a shopper closes their browser mid-payment. Without it those orders sit pending_payment until the stale-pending sweep catches them.

2. Allowlist this server's IP address

Order status checks and refunds only work from an IP registered against your API access code. Ask CCAvenue support to add it — everything else on this page is self-service; this is not.

Symptoms of a missing allowlist entry: placing orders works fine, but verification and refunds fail with an access-class error that does not mention IPs. The client logs a hint when it detects this.

3. Set the storefront origin

The shopper's browser is returned to this API, which settles the order and then forwards them to the storefront. That forward needs an absolute origin, taken from Settings → Storefront URLs → store_url (or the STOREFRONT_URL environment variable).

store_url defaults to empty. With nothing set, the order is still settled correctly, but the shopper is sent to a path on the API rather than the storefront and sees a 404. The API logs an OPS ALERT naming the setting when this happens — check for it after your first test payment.

The path appended to it is the storefront_return_path setting, defaulting to /orders. It receives ?order= and ?status=.

4. Confirm Instant Gratification is enabled

This integration assumes it. Without Instant Gratification, CCAvenue holds successful payments in an unconfirmed state and auto-cancels them after 12 days. This platform does not send confirmations, so orders would show as paid here and be reversed at CCAvenue.

Confirm this with CCAvenue before going live. If your account cannot use Instant Gratification, the Confirm/Cancel API support this integration does not yet implement becomes a prerequisite — raise it before launch, not after.

Enabling at checkout

Admin → Settings → Payment, the enabled-providers matrix. CCAvenue supports both WEB and APP, so it can be ticked for either or both.

Enabling an unconfigured provider is allowed but pointless — it will fail loudly at place time. The gateway list flags unconfigured providers.

Storefront copy (label, description, ordering) is edited under the checkout-appearance settings alongside every other gateway.

Refunds

With allow_refunds on, staff refund CCAvenue orders from the order page like any other gateway, through the provider-neutral routes on admin/orders. Full and partial refunds are both supported.

CCAvenue answers synchronously — success or failure arrives on the same call, unlike PhonePe where a webhook resolves it later. A refund therefore lands COMPLETED or FAILED immediately with no pending window.

Requires the IP allowlist above. With allow_refunds off, the neutral refund endpoint rejects CCAvenue orders and the fallback is to refund in the MARS panel and record it via POST /admin/orders/:id/mark-refunded.

Going live

Switch Environment to Production and paste the live credentials. Test credentials do not work against the production host and vice versa.
Confirm the production server's IP is allowlisted — it is a different host from staging.
Re-register all three URLs against the production MARS account.
Place one real low-value order end to end and refund it.

Troubleshooting

Symptom	Likely cause
Every transaction rejected at the billing page	Working key wrong for the selected environment, or credentials from the other environment.
Payment succeeds but the order stays `pending_payment`	Return URLs not registered, or not publicly reachable. Check the notification URL specifically.
Order settles correctly but the shopper lands on a 404	`store_url` is unset. Look for the `OPS ALERT` in the API logs.
Verification and refunds fail while checkout works	Server IP not allowlisted in MARS.
Orders paid here, reversed at CCAvenue ~12 days later	Instant Gratification is off. See the checklist above.
Amount mismatch errors on settlement	Store currency and the `currency` setting disagree — CCAvenue does not convert.

Payment CCAvenue — Admin

On this page