Kredivo Authentication

generated: '2026-07-19'
method: searched
source: https://doc.kredivo.com/
docs: https://doc.kredivo.com/
api: Kredivo Checkout API
summary:
  types:
  - apiKey
  api_key_in:
  - body
  oauth2: false
  openid_connect: false
  mutual_tls: false
  http_basic: false
  http_bearer: false
model: static shared secret per merchant, carried in the JSON request body
note: |
  UPGRADED FROM DERIVED. The derived pass read `in: header` from
  openapi/kredivo-checkout-openapi.yml, but that is an artifact of OpenAPI being unable to express a
  body-carried credential — the securityScheme in the spec is documentation only. Kredivo's actual
  and only documented mechanism is a `server_key` field inside the JSON request body of every
  operation. This file records the real model.
schemes:
- name: serverKey
  type: apiKey
  in: body
  parameter: server_key
  required: true
  applies_to: every documented operation
  description: |
    A static per-merchant secret generated by Kredivo ("Each merchant will have server_key generated
    by Kredivo"), sent as a top-level field of the JSON request body. There is no Authorization
    header, no bearer token, no request signing and no client certificate.
  sources:
  - https://doc.kredivo.com/
  - openapi/kredivo-checkout-openapi.yml
environments:
- name: sandbox
  base_url: https://sandbox.kredivo.com/
  key: published openly in the documentation and shared across all integrators
  cross_reference: sandbox/kredivo-sandbox.yml
- name: production
  base_url: not published
  key: issued privately per merchant
  how_to_obtain: Request the live endpoint and credentials from merchops@kredivo.com.
key_properties:
  rotation:
    documented: false
    note: No key rotation procedure, self-service key management or dashboard credential UI is documented.
  expiry:
    documented: false
    note: Keys appear to be long-lived with no published expiry.
  environment_prefix: false
  environment_note: |
    Keys carry no test_/live_ style prefix, so a sandbox key and a production key cannot be told
    apart by inspection. The environment is determined solely by the host the request is sent to.
    Bind key and base URL together in configuration.
  multiple_keys:
    documented: false
    note: No documented support for multiple concurrent keys per merchant, which makes zero-downtime rotation impossible to reason about.
authorization:
  scopes: false
  roles: false
  least_privilege: false
  note: |
    There is no authorization model at all — no scopes, no roles, no per-operation permissions, no
    read-only credential. The single `server_key` grants the full surface: initiating credit
    purchases, cancelling transactions, reading consumer credit data and destroying stored consumer
    tokens. A merchant cannot issue a reduced-privilege credential to a subsystem, a vendor or an
    agent. This is the most significant authorization gap in the API.
  cross_reference: mcp/kredivo-mcp.yml
callback_authentication:
  mechanism: verification round trip, not a signature
  field: signature_key
  description: |
    Push notifications to the merchant's push_uri carry no HMAC or signature header. The merchant
    verifies authenticity by calling GET /kredivo/v2/update with the notification's `transaction_id`
    and `signature_key`. A failed verification returns "Field secret_key is INCORRECT."
  cross_reference: asyncapi/kredivo-checkout-webhooks.yml
transport_security:
  https: true
  note: All published Kredivo hosts serve over TLS 1.3. See security/kredivo-domain-security.yml.
  caveat: |
    Because the credential is in the request body rather than a header, it will be captured by any
    request-body logging in gateways, proxies, APM tools or error trackers on the merchant side.
    Body redaction rules must explicitly cover the `server_key` field — header-based secret scrubbing
    will not catch it.
gaps:
- No OAuth 2.0, OpenID Connect or any delegated authorization.
- No scopes, roles or least-privilege credentials.
- No documented key rotation, expiry or multi-key support.
- Credential in the request body rather than a header, complicating log redaction.
- No signed webhooks — authenticity requires a synchronous round trip per notification.
- Sandbox credentials are shared across all integrators rather than per-merchant.