> ## Documentation Index > Fetch the complete documentation index at: https://docs.y.uno/llms.txt > Use this file to discover all available pages before exploring further. # Affiliation field reference > Every field of the Yuno provider form in VTEX, with its format, default, minimum plugin version and an example. These are the fields of the Yuno provider form in VTEX, under **Store Settings → Payment → Providers**, in your Yuno affiliation. The [setup guide](https://docs.y.uno/docs/plugins/vtex/set-up-yuno-on-vtex.md) 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](https://docs.y.uno/docs/plugins/vtex/advanced-features.md#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](https://docs.y.uno/docs/plugins/vtex/advanced-features.md#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](https://docs.y.uno/docs/plugins/vtex/advanced-features.md#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](https://docs.y.uno/docs/plugins/vtex/advanced-features.md#order-modifications-changed-order-totals). **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. > [!WARNING] > > 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](https://docs.y.uno/docs/plugins/vtex/advanced-features.md#network-tokens-repeat-card-purchases). **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](https://docs.y.uno/docs/plugins/vtex/advanced-features.md#corporate-purchases-brazil). **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**: ```text theme={"theme":{"light":"github-dark","dark":"github-dark-dimmed"}} 1=www.example.com;2=b2b.example.com;18=members.example.com ``` ## Delay To Cancel How long VTEX waits for a pending payment, per payment method, before it cancels the order. * **Required**: No * **Default**: the window of each payment method, listed under [How long VTEX waits for a pending payment](#how-long-vtex-waits-for-a-pending-payment) * **Available on plugin**: **4.2.373 or later** 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](#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. ```text theme={"theme":{"light":"github-dark","dark":"github-dark-dimmed"}} Cards=259200;PicPay=1800 ``` ### 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. | Payment method | Default window | | :- | :- | | Cards and MONNET | 24 hours. A card payment that already exists and is under review (antifraud review or card challenge) gets 3 days. | | Boleto Bancário | The boleto's due date, with a 24-hour minimum. | | PIX | The QR code expiration, between 15 minutes and 1 hour. | | Apple Pay, Google Pay, Samsung Pay, Click to Pay and the other methods rendered by Yuno, PicPay, MercadoPagoPro, Nubank, Pagaleve | 1 hour. | 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. | Group | Names | Shortest wait | | :- | :- | :- | | `Cards`, or one card brand | Visa, Mastercard, American Express, Diners, Elo, Hipercard, Discover, JCB, Aura, Alelo, Privatelabels, Cobranded, Visa Electron, Débito Online, Maestro, Mastercard Debit, VirtualDebitElo, Elo Débito, Voucher. A brand's own pair wins over `Cards`. On the redirect (Legacy) checkout, `Cards` also covers Yuno Card. | 1 hour | | Methods rendered by Yuno | Apple Pay, Google Pay, Samsung Pay, C2P, Yuno C2P Golden, Fast payments with Mercado Pago, PSE, Safetypay, PagoEfectivo, Yuno Card, Yuno Wallet, Yuno Bank Transfer, Yuno Buy Now Pay Later, Yuno Payment Link, Yuno Ticket, and any other method name not listed here. | 1 hour | | Methods created on the server | Nubank, PicPay, MercadoPagoPro, Pagaleve Transparente, Pagaleve Pix A Vista Transparente, MONNET - CASH, MONNET - BANK TRANSFER. | 10 minutes | | Not configurable | Pix (follows the QR code expiration) and Boleto Bancário (follows the due date). On the redirect (Legacy) checkout, Yuno Ticket is a boleto and is not configurable either. | | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.