Skip to content
ESENGo to the Portal

How it works

Who does what in an integration, how merchant accounts are linked, and which integration model to choose.

STEP 1Actorswho uses which credentialSTEP 2EnvironmentsSandbox and ProductionSTEP 3LinkingOAuth, onceSTEP 4One integrationand locations to separate events

Actors and accounts

Each actor authenticates with a different credential, against a different API.

Which credential each actor uses and against which API.

  1. Your backend uses the clientId and clientSecret only on the Auth API, to exchange and renew tokens.
  2. To the Integration API it sends the merchant account's idToken.
  3. The merchant account uses its email and password once, on the OAuth authorization screen.
  4. The integration admin signs in to the Portal with their email and password.
  5. The payer uses no credential: it transfers to the charge's CVU or pays in the checkout widget.
Actor Who it is Credential Where it's used
Integrator Your company: the backend that creates charges The integration's clientId and clientSecret Only on the Auth API: /integration/oauth2/token, /refresh and /revoke
Integration admin Whoever configures the integration Portal email and password In the Portal
Merchant account The Chytapay account that receives the payments Its Chytapay email and password Once, on the OAuth authorization screen
Payer Whoever pays the charge None Transfers to the charge's CVU or pays in the checkout widget

To the Integration API your backend sends the merchant account's idToken as Authorization: Bearer, never the clientSecret. The token carries the integration (aud, the clientId) and the merchant account (sub). Without a link, the response is 403. The checkout widget uses the integration's publishable key (pk_test or pk_live) in the browser: see the widget keys.

Warning: The merchant account performs the OAuth authorization, not the integration admin. The admin's token doesn't work on the Integration API: it returns 401.

Sandbox and Production

Your integration is one, with two environments. Sandbox is for testing, with its own credentials and a test merchant account. Production has real merchant accounts and real money. You always enter through the same portal and switch with the environment selector.

You start in Sandbox. To move to Production you request it under Credenciales (Credentials): if the automatic check approves it, you generate the production credentials with the environment selector on Production, and if not, the request goes to review. The steps are in Getting started.

The path from Sandbox to Production.

  1. You test in Sandbox.
  2. You request Production under Credentials.
  3. An automatic check decides: if it approves, you generate the production credentials.
  4. If the check fails, the request goes to review. If they approve it, you generate the credentials.

The daily WhatsApp message cap is per integration: 20 in Sandbox and 200 initial in Production. See the limits.

Linking vs. recurring use

Linking happens once and needs a browser. Recurring use happens on every charge, server to server.

Linking: once, with OAuth

The merchant account authorizes your integration at GET /integration/oauth2/authorize, and your backend exchanges the code at POST /integration/oauth2/token for an idToken and a refreshToken, which you store. See the flow in Connect merchant accounts.

Recurring use: every charge, server to server

The idToken lasts 1 hour. Renew it with the stored refreshToken, as explained in Connect merchant accounts, and call the Integration API with Authorization: Bearer <idToken> to create charges. If the admin unlinks the merchant account, you can no longer charge on its behalf, but its pending charges are not canceled.

One integration and its locations

Everything you configure lives in the integration: clientId and clientSecret, redirect_uri, webhook URLs, signing secret and widget keys. Have a single integration, no matter how many customers or merchant accounts you have: don't create one per customer.

If each customer, branch or franchise has its own backend and needs to receive its own events, use locations. A location is a unit of your integration with its own webhook URL. Credentials and the signing secret stay the integration's: a location only changes where events go.

Note: Each integration has one webhook URL, and locations add one per location. An event with no destination isn't delivered. See Locations.

Portal map

In the Portal, the integration admin configures and operates only their own integration. The environment selector switches between Sandbox and Production.

Section What you do there
Dashboard Your integration's summary, the status of your production request and your daily caps, with Pedir más límite (Request more limit).
Credenciales (Credentials) Copy the clientId and the widget's pk, and configure its authorized domains. The clientSecret is shown only once, when created or rotated. You also request Production here.
Configuración (Settings) The webhook URL, its validation-token and the signing secret, the OAuth redirect_uri and the logo.
Webhooks Which webhook events you receive (this is where you turn on payment.unmatched, which is off by default), the test webhook and the delivery history.
Cuentas de comercio (Merchant accounts) The linked ones, the button to unlink and, in Sandbox, the test tokens.
Tenants Locations. Appears only if you have locations enabled: ask support to enable them.
Distribución (Distribution) Your commission on each payment.
Transacciones and Reportes (Transactions and Reports) Your integration's charges and payments.
Simulador de pagos (Payment simulator) A simulated incoming payment. Sandbox only.

Webhooks configures events, not payer notifications (WhatsApp and email), which are set on each charge. See event subscriptions.

Access

Sign in at chytapay.com.ar/portal/login with your email and password. If you don't have an account yet, choose Crear cuenta (Create account).

Glossary

Term What it is
Integration Your product registered in Chytapay, with its clientId, clientSecret, URLs and keys.
Merchant account The Chytapay account charges are created for. Linked through OAuth. The payer goes in customer.
referenceId Your charge ID, unique per integration and merchant account, canceled charges included.
Location A unit of your integration with its own webhook URL. In the API and the Portal, tenant.
Payer notification The message to the payer by WhatsApp or email. Not the same as a webhook event.
idToken The merchant account's token for the Integration API. Lasts 1 hour. Renewed with the refreshToken.

Next steps

Getting startedFrom sign-up to your first event, in Sandbox.Connect merchant accountsOAuth and tokens.Create chargesFields, states and batches.LocationsOne webhook URL per location.CommissionsCharge a commission on every payment.