The 14 options you'll find when setting up a Stripe connection in the Yuno dashboard: what each one changes in the requests Yuno sends to Stripe, when to turn it on, and what to confirm with Stripe first
Most settings are safe to leave off: the defaults give you a standard card flow. Turn one on when the situation in the last column applies to you. Every row links to the full explanation below
| Setting | What it controls | Turn it on when |
|---|---|---|
| Radar Fraud Analysis | Forwards a browser Radar session to Stripe for full fraud scoring | You have Radar contracted directly with Stripe |
| Review Status Differentiation | Surfaces Radar manual reviews as a distinct payment status | You hold captures until fraud review resolves |
| Embedded 3ds Flow | Lets shoppers complete 3DS challenges instead of being declined | You want Stripe to handle 3DS challenges in your checkout |
| 3DS Frictionless Only | Attempts invisible 3DS only; challenges fail fast for re-routing | Stripe is one leg of a routing or cascade strategy |
| 3DS Credentials | Acquirer data for an external 3DS provider (MPI) | You authenticate through Netcetera, CyberSource or similar |
| Enable MIT & stored credentials | Forwards CIT/MIT and card-on-file data to Stripe | You charge saved cards or run subscriptions |
| Enable setup_future_usage for CIT | Flags the first payment of an agreement for off-session reuse | Later charges may be routed to other providers |
| Eager tokenization | Pre-tokenizes the card during checkout to speed up authorization | Authorization latency matters and you accept the caveats |
| Enable on_behalf_of | Makes your connected account the merchant of record | You are a Stripe Connect platform or marketplace |
| Controller parameters | Special Connect mode: direct charges on connected accounts | Only under explicit guidance from Yuno |
| Send receipt_email parameter | Has Stripe email its receipt to the shopper | You want Stripe-branded receipts sent automatically |
| Dynamic Metadata Configuration | Maps your Yuno metadata keys to Stripe metadata keys | You need your own metadata visible in Stripe |
| Disable AFT information submission | Suppresses account-funding fields even if your API sends them | Your Stripe account is not enabled for AFT processing |
| Transaction identification from | Whether your merchant_reference is stamped on Stripe payments | You reconcile in Stripe by your own order IDs |
One feeds data into Stripe Radar, the other surfaces Radar's verdicts back to you. They work independently and are often enabled together
Enables Stripe Radar scoring with full browser signal. When checked, the Yuno SDK creates a Radar session in the shopper's browser using your Stripe publishable key, and Yuno forwards it on every payment as radar_options[session]. Radar's rules then score with complete device and behavioral data, exactly as on a native Stripe integration
Yuno forwards the signal; the fraud analysis runs in your Stripe account. When unchecked, the session is never sent and Radar scores with much weaker data. To see Radar's manual-review verdicts in Yuno responses, also enable Review Status Differentiation below
By default, an authorization that Stripe Radar flags for manual review is reported by Yuno as a plain SUCCEEDED, indistinguishable from a clean approval. With this enabled, those payments return status SUCCEEDED with sub-status PENDING_IN_REVIEW, plus a provider_review_id to track the review in Stripe
Your payment-status handling must accept the PENDING_IN_REVIEW sub-status. Systems that expect a plain SUCCEEDED will start seeing a new value
Stripe-handled challenges, frictionless-or-fail-fast, or an external authentication provider. They are alternatives, not layers
Lets Stripe run 3D Secure challenges inside your checkout instead of failing the payment. Yuno sends error_on_requires_action=false plus a return_url: when the issuer demands a challenge, the shopper completes it and the payment resolves after authentication
Merchant-initiated payments (subscriptions, rebills) never receive challenges regardless of this setting, since no shopper is present to complete one
Attempts 3D Secure only when it can complete invisibly, through the frictionless flow or an exemption. Yuno sends request_three_d_secure=automatic together with error_on_requires_action=true: if the issuer insists on a challenge, the payment errors out immediately instead of showing one
Treat as mutually exclusive with Embedded 3ds Flow; if both are checked, Frictionless Only wins. It combines fine with Radar Fraud Analysis
Not Stripe's own 3DS. This holds the acquirer-side credentials needed when you authenticate through an external 3DS provider (an MPI such as Netcetera or CyberSource) and then process on Stripe. The MPI reads these values at authentication time, and the resulting proof (cryptogram, ECI, transaction ID) is attached to the Stripe payment as external 3DS data
These two work as a pair: enable the first for any card-on-file or subscription use, add the second if rebills may be routed across providers
The master switch for card-on-file and merchant-initiated payments on Stripe. When on, Yuno translates the stored_credentials object from your payment requests into Stripe's credential-on-file parameters
These features, in particular mit_exemption, must be enabled on your Stripe account beforehand, otherwise Stripe rejects the requests. Confirm with your Stripe contact before turning this on
On the first customer-present payment of a subscription or unscheduled card-on-file agreement, Yuno sends setup_future_usage=off_session, telling the issuer upfront that the credential will be reused later without the shopper present
Only works if Enable MIT & stored credentials is also on; without it this setting has no effect
A latency optimization. Yuno pre-creates the Stripe payment method while the shopper is still on the checkout page, between card capture and the moment they press Pay. The authorization then references the pre-created token instead of waiting for Stripe tokenization, which can otherwise add up to about three seconds
If your fraud strategy leans heavily on AVS checks or Stripe Radar, check with your Yuno contact before enabling. A known limitation where pre-created payment methods carried incomplete billing details, weakening AVS and Radar signal, is being fixed as of July 2026
Only relevant if you operate a platform with connected accounts. Standard Stripe merchants should leave both unchecked
Sets Stripe's on_behalf_of parameter, making the connected account (your sub-merchant) the merchant of record: their name on the shopper's card statement, and their country for fee and compliance purposes
Independent from transfer_data, which controls where the funds move. When off, on_behalf_of is never sent, even if your requests include the values
A special-purpose Connect mode for specific connected-account architectures. It switches from destination charges to direct charges: each payment is executed directly on the sub-merchant's Stripe account (via the Stripe-Account header), the commission split becomes Stripe's application_fee_amount, and transfer_data / on_behalf_of are skipped entirely
Enable only if Yuno has explicitly designed your Connect setup around this mode
When checked, card purchases include Stripe's receipt_email parameter, populated with the shopper's email from your Yuno payment request. Stripe then emails its own receipt to the shopper after a successful charge
In live mode Stripe sends this receipt regardless of the email settings in your Stripe dashboard. Enable only if you actually want Stripe-branded receipts going out. Card purchases only, not alternative payment methods
Controls which metadata from your Yuno payment requests is forwarded to Stripe, and under which names. You configure mapping rows of Merchant Key (the key you send in the Yuno API metadata object) to Provider Key (the key that appears on the payment in Stripe)
Stripe's legacy automatic metadata forwarding was retired in August 2025; this mapping is now the only way to get custom metadata into Stripe
AFT stands for Account Funding Transaction: payments that fund a wallet, prepaid account, or money transfer rather than purchase goods. If you send additional_data.order.account_funding (sender and beneficiary details) in the Yuno API, Yuno normally maps it into Stripe's sender_details and recipient_details fields (Visa requires both sides, Mastercard the recipient only)
Options: Yuno (default) and Merchant Custom (merchant_reference). Despite the name, this does not change which identifier Stripe uses for the transaction; that is always the Stripe PaymentIntent. It controls which references are stamped on the payment's metadata in Stripe
publishable key on hand.mit_exemption and stored-credential features confirmed as enabled on your Stripe account.PENDING_IN_REVIEW.