CashToCode

Connect CashToCode through Hyperswitch.

CashToCode settles payments as rewards rather than card or bank transactions, in two forms: Classic Reward and Evoucher. A payment either completes or it does not. There are no refunds, no cancellations, and no stored method to charge again later.

This is a redirect flow, and the redirect is not optional. Authorizing a payment does not charge anything. The response comes back with the attempt in AuthenticationPending and carries redirection data built from a pay_url; the customer has to be sent there to complete the payment at CashToCode. If you submit the payment and never present that redirect, nothing further happens: the attempt stays pending, and no callback arrives, because there is nothing to report on.

The two reward types redirect differently, which get_redirect_form_data() handles for you: Classic Reward posts to the pay_url as-is, while Evoucher parses the URL and sends its query parameters as form fields on a GET. Use the redirection data Hyperswitch returns rather than constructing the redirect yourself. The attempt moves to Charged only when CashToCode reports the payment succeeded, at the status mapping.

To connect CashToCode to your Hyperswitch account, follow Activate a connector on Hyperswitch, then return here for connector-specific behavior.

Status and capabilities

Integration status: live

Category: payment gateway

Webhook flows: payments

Payment method	Type	Mandates	Refunds	Capture methods	Countries	Currencies
reward	Classic Reward	not supported	not supported	automatic, manual, sequential automatic	249	160
reward	Evoucher	not supported	not supported	automatic, manual, sequential automatic	249	160

The table's currency count comes from the payment-method filters, not from CashToCode's credentials. Credentials exist for eleven currencies only, listed under Authentication, and a payment in any other currency has no credential set to authenticate with. Treat those eleven as the real list.

The matrix declares manual capture, but the capture flow is not implemented: build_request() returns FlowNotSupported. Use automatic capture. Cancellation is unavailable for the same reason, at Void. The capture gap is tracked upstream as issue 14350.

Authentication

CashToCode credentials are scoped per currency, not per connector account. For each currency you accept, you supply two sets of three:

Field	Classic Reward	Evoucher
Username	Username Classic	Username Evoucher
Password	Password Classic	Password Evoucher
Merchant ID	MerchantId Classic	MerchantId Evoucher

Eleven currencies are configured, each carrying its own set: AUD, CAD, CHF, CNY, EUR, GBP, INR, JPY, NZD, USD and ZAR. So a merchant accepting two currencies and both reward types fills in twelve values. The shape comes from cashtocode.connector_auth.CurrencyAuthKey, and the connector selects the set matching the payment's currency and reward type.

Before you start

1. Register with CashToCode at cashtocode.com.

2. Obtain a username, password and merchant ID for each currency you plan to accept, and for each reward type you plan to offer. Both reward types in one currency means six values.

3. Sign in to the Hyperswitch control center.

4. Enter those credentials during connector activation, and select automatic capture.

5. Enter your CashToCode webhook secret in Source verification key. Callbacks are rejected without it, and it is the only thing authenticating them. See Webhooks.

Webhooks

CashToCode posts a payment webhook, and two things about how Hyperswitch handles it are worth knowing before you rely on it.

There is no event list. Every callback that Hyperswitch accepts is treated as a successful payment. get_webhook_event_type() returns PaymentIntentSuccess for any non-empty body and EventNotSupported only for an empty one. It never reads a status field, so there is no failure or pending event to handle.

Classification is not the whole check. A callback must also parse as the expected object and carry a transactionId naming a payment, at get_webhook_object_reference_id(); a malformed body or one with no usable reference is rejected before any payment is touched. So a callback has to be well formed and name a real payment, but if it is, it means success and nothing else.

Verification is a shared secret in a header, not a signature. CashToCode sends the secret in the Authorization header, and verify_webhook_source() compares that header to your configured Source verification key as plain text. Nothing is computed over the body, so the check confirms the sender knows the secret and says nothing about what the body contains.

Two consequences follow. The secret travels in the clear on every callback, so anyone who can read one request, from a log or a proxy, holds it. And because a well-formed callback naming a real payment then counts as success, that secret is most of what it takes to drive a payment to succeeded. Treat the source verification key as a live credential and rotate it if a callback may have been logged.

There is no second opinion to fall back on. CashToCode does not implement payment sync: its PSync leaves build_request at the interface default, which builds no request and returns Ok(None), so Hyperswitch cannot re-check a payment after the fact. The callback is the only status signal, which is why the secret matters. Reconcile against CashToCode's own records rather than against Hyperswitch.

Source reference

Authentication and webhook behavior on this page is tied to Hyperswitch ec9d1d22bf0257b7de4d4d8bbba4e27fd520bdf7. See CashToCode connector source and CashToCode transformers.