> For the complete documentation index, see [llms.txt](https://nexon-3.gitbook.io/nexon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nexon-3.gitbook.io/nexon-docs/part-iv-products/04-product-stack/stablecoin-card.md).

# Stablecoin Card

The Stablecoin Card extends eligible digital value into everyday merchant acceptance, resting on a licensed issuer/operator.

*Product stage · Roadmap*

The Stablecoin Card is a bridge from eligible digital value to **everyday merchant acceptance**. It extends the NEXON value loop past marketplace inventory — to the corner shop, the restaurant, any terminal that takes a card.

## An interface does not issue a card

A card is issued by an **issuer**. The licensed issuer/operator determines eligibility, KYC/AML requirements, accepted funding assets, conversion, custody, authorization, settlement, fees, limits, refunds, disputes and cardholder protections. Card-network and merchant rules apply on top.

NEXON's side of the work is joining up the experience: prepare an eligible funding route, show the quote and costs, request bounded approval, display authorization status, and reconcile the issuer's receipt. **The issuer has to stay visible** — never obscured behind an agent that looks like the approving financial institution.

## The target flow

{% stepper %}
{% step %}

### Choose a source and an amount

The user selects a supported funding source and a spending amount.
{% endstep %}

{% step %}

### Check

PayFi checks product and jurisdiction eligibility, reserve policy and quote freshness.
{% endstep %}

{% step %}

### Show

The interface shows conversion, fees, limits, issuer and expiry.
{% endstep %}

{% step %}

### Approve

The user approves the action as scoped.
{% endstep %}

{% step %}

### Execute

The issuer/operator handles funding, card authorization and settlement under its own terms.
{% endstep %}

{% step %}

### Reconcile

The Wallet records financial settlement **separately** from any merchant refund or dispute.
{% endstep %}
{% endstepper %}

Offline authorization, recurring merchant charges, tips, reversals and chargebacks each need product-specific handling. **None of them fits a generic blockchain-finality model.**

## Token and economics boundary

The approved Tokenomics does not designate NX as current card settlement fuel, nor XO as card collateral. NX's payment and fee roles belong to the long-term direction. If a future card supports NX directly or uses it in a disclosed conversion path, that support must name the price source, liquidity, spread, fee, custody and refund treatment.

Card economics and Staking Platform rewards and NX redemption burns **run on separate tracks**. A card transaction does not earn staking rewards because it shares an ecosystem, and a merchant refund is not governed by a redemption burn.

## What has to ship before launch

A named authorized operator, contractual allocation of responsibility, jurisdiction coverage, supported funding assets, custody and safeguarding terms, fraud and sanctions controls, security review, clear fees, customer support and dispute procedures. Issuer, dates, fee schedule and jurisdictions are [Open Parameters](/nexon-docs/appendix/open-parameters.md) (OP-P05).

*Previous:* [*Marketplace*](/nexon-docs/part-iv-products/04-product-stack/marketplace.md) *· Next:* [*Token Economics*](/nexon-docs/part-v-economics/05-tokenomics.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://nexon-3.gitbook.io/nexon-docs/part-iv-products/04-product-stack/stablecoin-card.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.