Skip to main content
These are the fields of the Yuno provider form in VTEX, under Store Settings → Payment → Providers, in your Yuno affiliation. The setup guide shows where the form is and which fields VTEX itself adds to it.

​
Affiliation Name

A human-readable name for this Yuno integration.
  • Required: Yes
You see this name when you pick the provider in a payment condition, so choose one that tells your affiliations apart, for example by country or by the Yuno account behind it. Example: Yuno Brazil

​
Account ID

Your Yuno Account ID.
  • Required: Yes
Find it in your Yuno dashboard under Developers → API Credentials. Example: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

​
Public API Key

Your Yuno Public API Key.
  • Required: Yes
Find it in your Yuno dashboard under Developers → API Credentials. Its prefix decides the Yuno environment the store uses: dev_, staging_, sandbox_ or prod_. Example: sandbox_pub-xxxxxxxx

​
Private Secret Key

Your Yuno Private Secret Key.
  • Required: Yes
Find it in your Yuno dashboard under Developers → API Credentials. It must belong to the same account and environment as the Public API Key. Example: xxxxxxxxxxxxxxxxxxxxxxxx

​
Main Account Name

The VTEX account that owns the order data, for multi-account setups.
  • Required: No. Leave it empty on a single-account store.
The plugin reads orders and order groups from this account. Set it together with Main Account App key and Main Account App token: if any of the three is empty, the plugin ignores all of them. See Multi-account for which setups need it. Example: mystoreparent

​
Main Account App key

Application Key of the main VTEX account.
  • Required: No. Only with Main Account Name.
The plugin uses it to call VTEX APIs on behalf of the main account. See Multi-account. Example: vtexappkey-mystoreparent-XXXXXX

​
Main Account App token

Application Token of the main VTEX account.
  • Required: No. Only with Main Account Name.
It pairs with Main Account App key. See Multi-account. Example: XXXXXXXXXXXXXXXXXXXXXXXX

​
Soft Descriptor

Custom text that appears on the shopper’s card statement.
  • Required: No
Example: MYSTORE*ORDER

​
Create Customer

Creates a customer record in Yuno for each shopper.
  • Required: No
When set to Yes, the plugin creates a corresponding customer record in Yuno. Vault Card for Order Modification and Enable Network Tokens need it. Example: Yes

​
VTEX IO orderPlaced page URL

Where shoppers land after the payment.
  • Required: No
A custom URL where shoppers are redirected after payment. Example: https://www.example.com/checkout/orderPlaced

​
Payment Mode

How the shopper pays: inside the checkout or on a redirect page.
  • Required: No
Choose Payment App to render the payment inside the VTEX checkout, or Legacy for stores on the VTEX Legacy checkout, which cannot render a Payment App: the shopper is redirected to a Yuno-hosted payment page instead. Default Payment App. Example: Payment App

​
Transaction Identification From

Which transaction ID the order shows.
  • Required: No
Choose Yuno TID to show Yuno’s transaction ID, or Provider TID to show the transaction ID assigned by the payment provider that processed the payment. When the provider sends no transaction ID, the Yuno ID is shown. Default Yuno TID. Example: Yuno TID

​
Antifraud Providers for Split Orders

Which antifraud providers receive the shared session on split orders.
  • Required: No
  • Default: all four providers on plugin 4.2.362 or later; RISKIFIED and CYBERSOURCE on earlier versions.
Write a comma-separated list from RISKIFIED, CYBERSOURCE, SIGNIFYD and CIELO_CYBERSOURCE_FRAUD. If you fill it in, only the providers you list receive the session. Example: RISKIFIED,CYBERSOURCE

​
Vault Card for Order Modification

Lets the plugin charge the difference when an order total increases.
  • Required: No. Needs Create Customer set to Yes.
When set to Yes, the plugin securely stores the card used on each order and charges the additional amount automatically if the order total later increases. This is the only field that authorizes additional charges: when it is No, an order-total increase is declined even if the card was stored for network tokens. See Order modifications. Example: Yes

​
Enable Network Tokens

Stores cards so repeat purchases can use a network token.
  • Required: No. Needs Create Customer set to Yes.
When set to Yes, the plugin securely stores each card on its first purchase and recognizes it on later purchases by the same customer, so Yuno can process repeat purchases with a network token instead of the card number.
The toggle has no effect until Yuno activates network tokens on the routes your store uses. Until then cards are stored but no tokens are issued. Contact your Yuno KAM or support to activate it.
See Network tokens. Example: Yes

​
Use Corporate Buyer Data

Pays company orders under the company’s name and CNPJ. Brazil only.
  • Required: No
  • Default: No
When set to Yes, orders placed by a shopper checking out as a company (pessoa jurídica) are paid under the company’s legal name and CNPJ instead of the shopper’s personal name and CPF, on every payment method. See Corporate purchases. Example: Yes

​
Headless Payment Handoff

For marketplaces whose own headless checkout creates the Yuno payment.
  • Required: No
  • Default: No
  • Available on plugin: 4.2.356 or later for cards, 4.2.361 or later for PIX
This is an advanced setup for marketplaces that run their own headless checkout and create the Yuno payment themselves, for a cart that mixes the store’s own items and VTEX marketplace sellers. Enable it only with guidance from the Yuno team. When set to Yes, the plugin creates nothing in Yuno. Each authorization hands you a ready-to-send, authorization-only Yuno payment request for the VTEX part of the cart. You add the card token and the marketplace split, and create one payment that covers every seller order of the cart. The plugin then reports each order’s status from that payment and captures or refunds each order’s share separately. Cards and PIX only: any other payment method is declined. Example: Yes on the store that runs the headless checkout. Every other store keeps No.

​
Store Base Path

The URL path prefix of a store that is not served from the domain root.
  • Required: No
  • Available on plugin: 4.2.316 or later
Use it for a storefront at https://www.example.com/br instead of the domain root. It is the path the Payment App uses when it calls your store’s payment routes during checkout. Leave it empty when the store is served from the domain root.
  • Use plain path segments only: letters, numbers, - and _. No scheme, host, query string or dots.
  • A leading slash is added if missing.
  • A value that looks like a hostname is ignored, and the store behaves as if the field were empty.
Example: /br or /br/store

​
Send Order Sequence as Merchant Reference

Sends the VTEX order sequence as the payment’s merchant reference.
  • Required: No
  • Default: No
  • Available on plugin: 4.2.333 or later for PIX, boleto and the other methods created on the server; 4.2.355 or later for every payment method
When set to Yes, every payment sends the VTEX order sequence (the number shown in the VTEX order list, for example 1234567890123) as the payment’s merchant reference. A provider configured with a custom transaction identification, such as Mercado Pago, then shows that sequence as the external reference in its panel, as it did before you migrated to Yuno. When set to No, or when the sequence is not available, the reference is the VTEX order ID. Example: Yes

​
Sales Channel Domains

Maps each sales channel to the domain of its storefront.
  • Required: No
  • Available on plugin: 4.2.333 or later
Maps each VTEX sales channel (trade policy) ID to the public domain of its storefront, so the payment reports the storefront the order came from instead of the account’s default host. This improves reporting and reconciliation for stores that run several storefronts on one account.
  • Write id=domain pairs separated by ;. A , between pairs and a : between ID and domain are also accepted.
  • An https:// prefix and trailing slashes are removed, and malformed pairs are skipped.
  • Sales channels you do not list use the order’s own storefront host. Stores that leave the field empty keep the current behavior.
Example:

​
Delay To Cancel

How long VTEX waits for a pending payment, per payment method, before it cancels the order. When a payment is still pending, VTEX waits for a set time before it cancels the order and releases its stock. This field sets that time per payment method.
  • Write Method=seconds pairs separated by ;. A , between pairs and a : between name and seconds are also accepted.
  • Method is the payment method name as it appears when you create a payment condition in VTEX (for example Mastercard, MercadoPagoPro or Pagaleve Transparente), not the name you give the condition. The full list is under Payment methods you can set in Delay To Cancel.
  • Names are matched without regard to case, but accents must match, as in Elo Débito.
  • Cards applies to every card brand, and a brand’s own pair wins over Cards.
  • Seconds must be a whole number between 600 (10 minutes) and 2592000 (30 days). A pair outside that range, or a malformed one, is ignored and the method keeps its default.
  • Cards and the methods rendered by Yuno (Apple Pay, Google Pay, Samsung Pay, Click to Pay) never wait less than one hour: a shorter value becomes one hour.
  • For cards, the value also replaces the 3-day window of a card payment that already exists and is still pending (antifraud review or card challenge). A short value therefore cancels reviews that would have been approved later.
  • PIX and Boleto Bancário cannot be configured: PIX follows the QR code expiration and boleto its due date.
  • The headless payment handoff ignores the field and always waits 1 hour.
Example: cards wait 3 days and PicPay 30 minutes.

​
How long VTEX waits for a pending payment

Without the Delay To Cancel field, each payment method uses the window below on plugin 4.2.372 or later. Earlier versions waited up to 24 hours for wallets, and some pending answers carried no window at all. The field replaces the window for every method except PIX and Boleto Bancário. On the redirect (Legacy) checkout the defaults differ: PIX, PicPay, MercadoPagoPro and Nubank wait 1 hour, and every other method, boleto included, 24 hours. The headless payment handoff always waits 1 hour.

​
Payment methods you can set in Delay To Cancel

Write the name exactly as VTEX shows it when you create the payment condition. Case does not matter; accents and spaces do. A value below the shortest wait of its group is raised to that wait.