Skip to main content
A provider is a payment processor, acquirer, or gateway that Yuno connects to on your behalf. Providers are the entities that actually authorize and settle transactions — Yuno sits in front of them and handles routing, failover, and normalization so your integration stays the same regardless of which provider processes a given payment.

How providers work in Yuno

You do not integrate with providers directly. Instead, you connect to Yuno once and configure providers through the Dashboard. When a payment request arrives, Yuno’s routing engine evaluates your routing rules and selects the most appropriate provider for that transaction. This means:
  • Adding a new provider does not require changes to your API integration
  • Switching the primary processor for a payment method is a Dashboard configuration change, not a code change
  • Yuno normalizes provider-specific response formats into a consistent API response structure

Provider types

Card processors

Acquirers and gateways that authorize credit and debit card transactions. Examples include Adyen, Stripe, and regional acquirers.

Bank transfer providers

Providers that facilitate bank-to-bank payments such as PIX (Brazil), ACH (US), or SPEI (Mexico).

Local payment method providers

Providers specializing in regional methods such as OXXO, Boleto, iDEAL, and other country-specific instruments.

Configuring providers

Providers are configured in Dashboard → Connections. Each connection represents a merchant account with a specific provider and includes:
  • API credentials for that provider (stored securely by Yuno)
  • Enabled payment methods and countries for that connection
  • Environment (sandbox or production)
Once a connection is active, it becomes available to your routing rules.
You can have multiple connections to the same provider — for example, separate accounts for different business lines or currencies — and route between them using routing rules.

Routing

Yuno’s routing engine determines which provider handles each transaction based on rules you define. Several routing strategies are available:

Routing rules

Static rules that route based on criteria such as payment method, country, currency, amount range, or customer attributes. Configured in Dashboard → Routing.

Smart routing

Yuno’s data-driven routing layer that dynamically selects the provider most likely to authorize a given transaction, based on historical approval rates across your connected providers.

BIN routing

Routes card transactions based on the Bank Identification Number (BIN) — the first six to eight digits of the card number. Use BIN routing to direct specific card types, issuing banks, or card programs to the provider best positioned to process them.
Routing configuration changes take effect immediately and apply to new payment requests. In-flight transactions are not affected.

Providers in API responses

When Yuno processes a payment, the API response includes fields that identify which provider handled the transaction and what the provider returned.
FieldLocation in responseDescription
transaction.providerPayment response bodyYuno’s internal identifier for the provider that processed the payment
transaction.provider_codePayment response bodyThe provider’s own reference code for the transaction (useful for reconciliation and support)
transaction.provider_messagePayment response bodyHuman-readable message from the provider, typically present on declines

Example

{
  "id": "pay_abc123",
  "payment_status": "DECLINED",
  "transaction": {
    "provider": "ADYEN",
    "provider_code": "51",
    "provider_message": "Insufficient funds"
  }
}
In this example, provider_code: "51" is the issuer decline code returned by the provider. These codes are provider-specific — the same decline reason may use different codes across providers.
Do not display raw provider_code or provider_message values to end users. Map them to user-friendly messages in your application layer. Exposing raw provider codes can reveal integration details and may cause user confusion.