Skip to main content
A condition matches against an attribute of the incoming payment.
Conditions inside the same condition_sets[].conditions[] are combined with logical AND. For OR semantics, split into multiple condition sets ordered by sort_number.

​
condition_type catalog

​
conditional operators

​
Special cases

  • AMOUNT requires currency. Comparisons are FX-naive; only payments whose currency matches the rule’s currency are evaluated.
  • METADATA requires key. Compares payment.metadata[key]. If the key is absent on the payment, the condition does not match — absence is not equality.
  • Card-only condition types (CARD_ISSUER_COUNTRY, CARD_TYPE, CARD_BRAND, CARD_BIN) are only valid when payment_method = "CARD".
  • COUNTRY vs CARD_ISSUER_COUNTRY. The two are sourced independently: COUNTRY matches the transaction country your backend submits in the payment request, while CARD_ISSUER_COUNTRY matches the issuer country Yuno’s own BIN lookup derives from the card number. The same payment can be COUNTRY = US and CARD_ISSUER_COUNTRY = GB at once. The BIN lookup runs before a provider is selected, is identical in sandbox and production, and reflects real-world BIN-registry data — never the processor’s view of the card.
  • Numeric values are submitted as strings to match the values: string[] schema. Yuno parses them based on the condition_type.

​
Testing CARD_ISSUER_COUNTRY rules in sandbox

Provider test-card countries are simulator metadataThe “country” a payment provider documents for its test cards exists only inside that provider’s own test environment — it is simulator metadata attached to the PAN, not a property of the number itself. Yuno’s BIN lookup resolves the real-world registry entry instead, so a test card’s documented country and its resolved card_data.country_code in Yuno usually differ.
Two examples with Stripe’s test cards: To verify a CARD_ISSUER_COUNTRY rule end-to-end today, work with resolved values rather than documented ones — the lookup is deterministic:
  1. Run one sandbox payment with a candidate test card.
  2. Read card_data.country_code from the payment (payment details in the dashboard, or the Retrieve Payment response).
  3. Build the rule against that value. For example, 4242 4242 4242 4242 is a dependable GB card end-to-end.
The same caveat applies to every BIN-derived condition (CARD_TYPE, CARD_BRAND), though country is where provider test-card documentation diverges most often.