Skip to content

Logo

Cirxus Pay

Supports in this guide: Payments

Provider website: cirxus-pay.com


What you need to do for start processing transactions (brief summary)

  1. Choose account type
  2. Get your credentials (from Cirxus Pay)
  3. Connect in Dashboard
  4. Send an API request

Choose account type

Cirxus Pay can be connected in different ways (depending on your needs):

  • If you do H2H card payments (card data sent directly) -> choose H2H Merchant account

If you're not sure which one to use, confirm with your Corefy account manager.


Prerequisites: get from Cirxus Pay

Submit a connection request via cirxus-pay.com or contact your Cirxus Pay account manager directly to get your account verified and receive the following credentials:

  • API Key -> Corefy field api_key -> your Cirxus Pay API key, used to authenticate every request -> where to find: Cirxus Pay backoffice / issued by Cirxus Pay manager
  • API Type -> Corefy field api_type -> choose Server-to-Server or Direct Post - see Additional info for what each one means for your PCI scope -> where to find: Cirxus Pay backoffice / issued by Cirxus Pay manager
  • S2S Token (required only if API Type is Server-to-Server) -> Corefy field s2s_token -> authenticates the card-data submission step when using Server-to-Server -> where to find: Cirxus Pay backoffice / issued by Cirxus Pay manager
  • Brand ID -> Corefy field brand_id -> identifies your brand/storefront on Cirxus Pay's side -> where to find: Cirxus Pay backoffice / issued by Cirxus Pay manager
  • Webhook Public Key (optional) -> Corefy field webhook_public_key -> used to verify the signature on incoming callback notifications; if left blank, Corefy automatically requests/creates one from Cirxus Pay the first time the connection is tested -> where to find: Cirxus Pay backoffice / issued by Cirxus Pay manager
  • Strict customer data validation (optional) -> Corefy field strict_customer_data_validation -> select which customer fields (Phone, Name, Street, Country, Individual Tax ID, City, Postcode, Region) Corefy should require locally before sending a request to Cirxus Pay -> where to find: Cirxus Pay backoffice / issued by Cirxus Pay manager

Payments processing (connect H2H Merchant account, create payment-invoice)

Connect H2H Merchant account in Corefy Dashboard

Step 1 - Open connection form

Open Cirxus Pay in the provider directory and press Connect at Cirxus Pay Provider Overview page in the New connection section. Choose H2H Merchant account.

Step 2 - Fill in fields and select settings

  • API Key
  • API Type -> Server-to-Server or Direct Post
  • S2S Token (required only for Server-to-Server)
  • Brand ID
  • Webhook Public Key (optional)
  • Strict customer data validation (optional, multi-select)

Choose Currency and Features. USD is the only currency currently supported; check with your Corefy account manager which features are enabled for your account.

Success

You have connected Cirxus Pay H2H Merchant account!


First request to Corefy API (MIN)

What it does: creates a payment-invoice. customer.email is required - Cirxus Pay's own connector rejects the request locally if it's missing, and there's no Constants fallback for it.

Payment - MIN

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "e2e594d7-eff2-41e9-9273-610670646111",
      "service": "payment_card_usd_hpp",
      "currency": "USD",
      "amount": 10,
      "customer": {
        "reference_id": "6164d44c-10de-48cd-91a4-735fc7c64f58",
        "email": "johnsmith@gmail.com"
      }
    }
  }
}

Payment - MAX

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "287e6567-3625-43f3-aac4-ff3002c6742d",
      "service": "payment_card_usd_hpp",
      "currency": "USD",
      "amount": 10,
      "customer": {
        "reference_id": "cus_123",
        "name": "John Smith",
        "email": "johnsmith@gmail.com",
        "phone": "+15551234567",
        "individual_tax_id": "82189212198",
        "address": {
          "country": "US",
          "city": "New York",
          "region": "NY",
          "full_address": "1 Main street",
          "post_code": "10001"
        }
      }
    }
  }
}


Extended request (MAX)

Why add extra fields (typical reasons): - Provide additional customer details for compliance/reconciliation - Positively influence conversion rate - Include optional fields required by your specific flow


Options

Options are configured on the Corefy side and affect how Corefy builds provider requests or processes responses.

Currently available options (5)

  • check_trans_allowed - runs a pre-flight check before invoking the transaction.
  • custom_finalization_with_delay - delays finalization by a number of seconds before rechecking the transaction status.
  • finalize_on_complete_sale - finalizes the transaction right after the complete-sale (3DS) step, instead of waiting for a callback/reconciliation.
  • fail_errors_on_sale - controls whether a provider error during the direct Sale step fails the transaction immediately.
  • send_true_js_enabled - forces the "JavaScript enabled" browser flag to true on the Sale request, regardless of what the customer's actual browser reports.
check_trans_allowed

What it does: before invoking the transaction, asks Cirxus Pay whether this customer is allowed to transact; if not, Corefy rejects the request locally instead of invoking it.

When to use: enable only if instructed by Cirxus Pay or your Corefy account manager.

Default: false

Allowed values: true / false

custom_finalization_with_delay

What it does: instead of finalizing immediately after a callback/reconcile response, Corefy waits the configured number of seconds and then rechecks the transaction's status before finalizing.

When to use: when Cirxus Pay's own status updates lag behind the real outcome and a short delay improves finalization accuracy.

Default: not set (no delay)

Allowed values: any number of seconds

finalize_on_complete_sale

What it does: finalizes the transaction right after the complete-sale (3DS) step, instead of waiting for an asynchronous callback or a separate reconcile call.

When to use: when your flow needs an immediate final status at complete-sale time.

Default: false

Allowed values: true / false

fail_errors_on_sale

What it does: when enabled, a provider error returned during the direct Sale step fails the transaction outright; when disabled, Corefy treats it as pending and relies on reconciliation to determine the final status.

When to use: keep the default unless your account manager advises otherwise.

Default: true

Allowed values: true / false

send_true_js_enabled

What it does: overrides the browser-detected "JavaScript enabled" flag sent on the Sale request to always be true.

When to use: if Cirxus Pay requires this flag to be true for your integration regardless of the customer's actual browser capabilities.

Default: false

Allowed values: true / false


Constants (fallback fields)

Constants are static values that Corefy can send to Cirxus Pay instead of dynamic data from your API request, when those fields are missing in the request. They do not apply to customer.email, which has no Constants fallback and must always be present in the request.

Priority (predictable rule): 1. If a value is present in the request -> Corefy uses the request value 2. Else if the constant is set -> Corefy uses the constant 3. Else -> the field is simply not sent to Cirxus Pay

Currently available constants (constant -> Corefy API field)

  • PHONE -> customer.phone
  • FULL_NAME -> customer.name
  • STREET_ADDRESS -> customer.address.full_address
  • COUNTRY -> customer.address.country
  • PERSONAL_CODE -> customer.individual_tax_id
  • CITY -> customer.address.city
  • ZIP_CODE -> customer.address.post_code
  • STATE -> customer.address.region

Additional info

  1. API Type. Server-to-Server means Corefy submits card data to Cirxus Pay on your behalf via API (requires the S2S Token). Direct Post means the customer's browser posts card data directly to Cirxus Pay, bypassing Corefy's servers - ask your account manager which one fits your PCI scope.

  2. Callback routing. Callbacks use a dedicated endpoint, /cirxuspay/callback. Provide the Webhook Public Key (or leave it blank to have Corefy request/create one automatically on the first connection test) so Corefy can verify the signature on incoming callbacks.

  3. No hardcoded fallback values. If a customer field is missing from both the request and from Constants, Corefy simply omits it from the request to Cirxus Pay - it never substitutes a placeholder email, address, or phone number on your behalf. The one exception is customer.email, which cannot be omitted at all (see above).

  4. Refunds. Partial refunds are supported, but only one refund can be issued per transaction - a second refund attempt on the same transaction is not supported.


FAQ / Troubleshooting

  • Invalid credentials / auth error -> verify you used the correct API Key / S2S Token for your account
  • Currency not supported -> Cirxus Pay currently supports USD only; confirm this matches your needs
  • Missing customer data fields -> set Constants (see "Constants") or provide the fields directly in the API request; customer.email must always be sent, Constants cannot cover it
  • "Customer email is required" error -> customer.email is mandatory on every request to Cirxus Pay and has no fallback
  • Not sure which account type to use? -> ask your Corefy account manager

Question

Still looking for help connecting your Cirxus Pay account? Please contact our support team!