How a payment works

This page explains what happens between the moment you render the checkout and the moment you receive the webhooks.

Your server          Browser (SDK iframe)            CreditCore API                 Gateway
    │                        │                              │                           │
    │ POST /api/session ───────────────────────────────────▶│                           │
    │◀──────────────────────────────── sessionId (5 min) ───│                           │
    │── render page ────────▶│                              │                           │
    │                        │ submit payment (encrypted card)                          │
    │                        │─────────────────────────────▶│ validate card ───────────▶│
    │                        │                              │ charge / pre-auth ───────▶│
    │                        │◀──────────── { code: "OK" } ─│                           │
    │◀───────────────────────────────── webhooks (async) ───│                           │

1. Session. Your backend creates a session for the domain that will show the checkout. The session is valid for 5 minutes.

2. Checkout. The SDK loads a secure card form in an iframe. When the buyer clicks Pay, the card number and CVC are encrypted in the browser and sent to CreditCore together with the email, name, productId, sessionId and any additionalData you configured.

3. Session & product checks. CreditCore verifies that the session exists, has not expired and matches the domain, and that the product exists and is active for your account.

4. Merchant account selection. CreditCore picks a merchant account (MID) from the product’s merchant-account group that accepts the card type.

5. Card validation. The card is validated with the gateway (a zero-amount verification). If validation fails, the checkout returns CREDITCARD_VALIDATION and nothing is charged. Blocked BINs return BIN_BLACKLIST.

6. Duplicate check. If the same email + card already has an active subscription to a product that doesn’t allow multiple subscriptions, the checkout returns ALREADY_SUBSCRIBED.

7. Charge. Depending on the product type, CreditCore charges the card, places a pre-authorization, or schedules the first charge for later.

8. Response and webhooks. The SDK receives { "code": "OK", "customerId": "…" }. CreditCore then sends a TRANSACTION webhook (if a charge was attempted) and a CONVERSION webhook.

`OK` means the customer was created — not that the charge succeeded

The checkout response confirms that the card was validated and the customer was created. The result of the charge itself is only reported in the TRANSACTION webhook (success, response_text). Always use webhooks to grant access or fulfil orders.

Domain matching

The session is bound to the domain you passed to POST /api/session. At checkout, CreditCore compares it with the domain option you pass to the SDK (sent as landingDomain). If they don’t match, the checkout fails.

• Use the host name only: shop.example.com, not https://shop.example.com/checkout.
• Always pass the same value in both places.

Timing

Step	Typical time
Session lifetime	5 minutes
Checkout response	1–3 seconds
Webhook delivery	Seconds after the response (asynchronous)
Renewals	Processed every hour for customers due in that hour