Postman Generator Context

This page is indexed for Ask AI and the Postman generator. It captures the operational context from the shared Postman examples without copying secrets, bearer tokens, API keys, internal URLs, or stale generated payloads.

Source of truth

The generator uses the OpenAPI rail catalog and node-wrapper schemas as the public contract:

• x-rail-catalog defines the supported rails, directions, countries, currencies, lifecycle notes, and node keys.
• payment-node-type defines the node type enum used in origins[] and destinations[].
• node-wrapper maps each published schema to its rail object, such as CVU -> cvu, PCT -> pct, FEDNOW -> fedNow, or CRYPTO -> wallet; rail metadata supplies the same node-key rule for catalog entries such as PAGO_MOVIL -> pagoMovil.
• Request examples must follow those node keys and must not use internal notification endpoints.

Core model

An identity is the actor that owns accounts and permissions. An account is an internal Conomy balance identified by accountNumber. A payment moves funds between origins and destinations.

Pay-in flows use an external rail in origins and an internal ACCOUNT node in destinations.

Pay-out flows use an internal ACCOUNT node in origins and an external payout rail in destinations.

The generator must discover rail availability for the selected identity and currency before creating payment bodies. Use GET /payments/available-products for the full per-currency product view, GET /payment-origins for origin nodes, and GET /payment-destinations for destination nodes.

Do not generate externalId or identityExternalId in payment examples. Chain from Conomy IDs returned by API responses, such as identityId, accountNumber, and paymentId.

Amount engine modes

purchaseAmount and totalAmount are different amount-engine modes and must not be sent together in the same request body.

• Use purchaseAmount with purchaseCurrency when the customer/source amount is known first.
• Use totalAmount with currency when the final/destination amount is known first.
• The Argentina collection uses purchaseAmount for CVU dynamic/static pay-in, totalAmount for PCT QR pay-in, totalAmount for CVU pay-out, and purchaseAmount for BANK_ACCOUNT pay-out.

Required Argentina CVU/PCT collection

When the user asks for:

1- Pay-in
a) Desde CVU dinamico
b) Desde CVU estatico
c) Desde PCT (QR)

2- Pay-out
d) Hacia CVU
e) Hacia Bank Account

f) API de configuracion de webhook

Generate one collection with these folders, in this order:

1. Setup: POST /auth.
2. Identity and Account Context: create or store an identityId, then read an existing ARS internal accountNumber with GET /accounts.
3. Rail Discovery: GET /payments/available-products?identityId={{identityId}}&currencies=ARS, then GET /payment-destinations?accountNumber={{accountNumber}}.
4. Pay-in A - CVU Dynamic: POST /payments, POST /payments/{id}/captured, then GET /payments/{id}.
5. Pay-in B - CVU Static: GET /payment-origins, then POST /payments with the fixed cvu.code in the CVU origin.
6. Pay-in C - PCT QR: POST /payments, then GET /payments/{id}. PCT does not use the CVU capture step in the generated QR flow.
7. Pay-out D - CVU: POST /payments, POST /payments/{id}/captured, then GET /payments/{id}.
8. Pay-out E - Bank Account: POST /payments, POST /payments/{id}/captured, then GET /payments/{id}.
9. Webhook Configuration: PUT /clients/webhook, GET /clients/webhook, optional GET /clients/webhook?flavor=cvu.static, optional GET /clients/webhook?flavor=cvu.dynamic, and an example payload for the merchant’s webhook receiver.

CVU dynamic pay-in

Dynamic CVU is created by Conomy per payment attempt. The request creates a TOPUP_ACCOUNT or PURCHASE payment with a CVU origin and an internal ACCOUNT destination. Do not send cvu.code in the create request.

After creating the payment, call POST /payments/{id}/captured without a request body in the generated collection. Read and store origins[0].cvu.code from the capture or payment response. That dynamic CVU code is the code the payer uses for the bank transfer.

Canonical body shape:

{
  "identityId": "{{identityId}}",
  "accountNumber": "{{accountNumber}}",
  "product": "ARS:ARS",
  "type": "TOPUP_ACCOUNT",
  "purchaseAmount": "10000",
  "purchaseCurrency": "ARS",
  "currency": "ARS",
  "origins": [
    {
      "name": "CVU",
      "type": "CVU",
      "currency": "ARS",
      "cvu": {
        "customer": {
          "firstName": "Maria",
          "lastName": "Gomez",
          "email": "maria.gomez@example.com"
        }
      }
    }
  ],
  "destinations": [
    {
      "type": "ACCOUNT",
      "currency": "ARS",
      "identity": { "identityId": "{{identityId}}" },
      "account": { "accountNumber": "{{accountNumber}}" }
    }
  ]
}

CVU static pay-in

Static CVU uses a fixed CVU assigned to the identity/account. For static CVU, first call:

GET /payment-origins?accountNumber={{accountNumber}}&currency=ARS

Select the CVU node and use its cvu.code in the CVU origin when creating the static CVU payment. In the static flow, the client supplies the fixed CVU code; in the dynamic flow, Conomy returns the CVU after capture/status.

PCT QR pay-in

PCT is an Argentina QR pay-in rail. Use PCT as the origin and ACCOUNT as the destination. The PCT node must include pct.customer.phoneNumber, pct.customer.phoneNumberPrefix, and pct.customer.email. Include redirect URLs when building direct payment flows.

The generated PCT QR pay-in uses the totalAmount amount mode. Do not include purchaseAmount, purchaseCurrency, or per-node amount fields for the single-origin/single-destination PCT example.

PCT QR is not a CVU flow. Do not call GET /payment-origins, do not send cvu.code, and do not add POST /payments/{id}/captured in the generated PCT QR folder. Create the payment, then read it to store origins[0].pct.qrCode.

Canonical body:

{
  "identityId": "{{identityId}}",
  "accountNumber": "{{accountNumber}}",
  "product": "ARS:ARS",
  "type": "TOPUP_ACCOUNT",
  "totalAmount": "10000.00",
  "currency": "ARS",
  "origins": [
    {
      "name": "PCT",
      "type": "PCT",
      "currency": "ARS",
      "pct": {
        "successUrl": "https://yourapp.com/success",
        "failedUrl": "https://yourapp.com/failed",
        "customer": {
          "phoneNumber": "1155551234",
          "phoneNumberPrefix": "54",
          "email": "maria.gomez@example.com"
        }
      }
    }
  ],
  "destinations": [
    {
      "type": "ACCOUNT",
      "currency": "ARS",
      "identity": { "identityId": "{{identityId}}" },
      "account": { "accountNumber": "{{accountNumber}}" }
    }
  ]
}

The response contains pct.qrCode. In sandbox and staging this is a simulator URL; in production it is the real QR payload.

CVU pay-out

CVU is a two-way rail. For pay-out, use an internal ACCOUNT origin and a CVU destination. The destination must include cvu.code because the recipient CVU is supplied by the client.

Canonical destination:

{
  "name": "CVU",
  "type": "CVU",
  "currency": "ARS",
  "cvu": {
    "code": "{{recipientCvu}}"
  }
}

After creating the WITHDRAWAL_ACCOUNT payment, call POST /payments/{id}/captured, then poll GET /payments/{id} or rely on webhooks until a terminal status.

Bank Account pay-out

Bank Account payout uses an internal ACCOUNT origin and a BANK_ACCOUNT destination. Use GET /payment-destinations?accountNumber={{accountNumber}} before rendering the destination form.

Canonical destination for Argentina:

{
  "name": "BANK_ACCOUNT",
  "type": "BANK_ACCOUNT",
  "currency": "ARS",
  "bank": {
    "accountNumber": "0000267900000001588730",
    "bank": "BANCO_CMF",
    "currency": "ARS",
    "typeAccount": "CHECKING",
    "accountHolder": "Maria Gomez",
    "accountHolderDni": "20219636890",
    "country": "ARG"
  },
  "customer": {
    "firstName": "Maria",
    "lastName": "Gomez",
    "documentType": "DNI",
    "documentNumber": "20219636890",
    "country": "ARG",
    "email": "maria.gomez@example.com"
  }
}

After creating the WITHDRAWAL_ACCOUNT payment, call POST /payments/{id}/captured, then read status with GET /payments/{id}.

Webhook configuration

Webhook setup is public client configuration, not an internal notification audit API.

Use:

PUT /clients/webhook
GET /clients/webhook
GET /clients/webhook?flavor=cvu.static
GET /clients/webhook?flavor=cvu.dynamic

Use request body:

{
  "webhookUrl": "{{webhookUrl}}",
  "secretKey": "{{webhookSecret}}"
}

When separate CVU routing is required, include flavor: "cvu.static" for fixed CVU flows or flavor: "cvu.dynamic" for Conomy-created CVU flows.

Never add internal notification endpoints to public generated collections.