PYUSD와 결제형 스테이블코인
도입
PYUSD는 "PayPal 이름이 붙은 토큰"으로만 보면 구조를 놓친다. 발행자는 Paxos이고, PayPal/Venmo는 사용자가 접하는 결제·지갑 표면이며, public blockchain은 외부 지갑과 merchant가 정산을 확인하는 레이어다. 결제형 stablecoin을 설계할 때는 이 세 영역의 책임을 나눠야 한다.
Paxos는 PYUSD를 payments layer로 설명하고, reserve report와 attestation을 공개한다. PayPal은 PYUSD를 consumer payment, B2B payment, cross-border payment 같은 결제 use case에 연결한다. 따라서 이 강의의 핵심 질문은 "PYUSD가 좋은가 나쁜가"가 아니라 "checkout, refund, merchant settlement, reserve disclosure, supported chain을 어떤 운영 데이터로 관리할 것인가"이다.
학습 목표
- 결제형 스테이블코인의 UX, 규제, 운영 요구를 파악한다.
- consumer payment와 DeFi collateral 사용의 차이를 구분한다.
- issuer, wallet surface, public chain, merchant settlement의 책임을 나눠 설계한다.
개념 설명
PaymentRailSelected
결제형 스테이블코인의 UX, 규제, 운영 요구를 파악한다.
TransferAuthorized
발행/상환과 결제 상태가 분리되는가
ComplianceHold
이벤트와 내부 원장이 대조되는가
PaymentEvidence
PYUSD actor 책임표 만들기
1. PYUSD는 actor를 나눠 읽어야 한다
결제형 stablecoin은 토큰 컨트랙트 하나로 끝나지 않는다. 사용자는 PayPal/Venmo 안에서 보는 잔고와 외부 지갑에서 보는 온체인 잔고를 같은 돈처럼 느끼지만, 시스템 설계자는 책임 경계를 분리해야 한다.
| Actor | 맡는 역할 | 결제 제품에서 확인할 것 |
|---|---|---|
| Paxos | PYUSD issuer, reserve report/attestation, mint/redeem infrastructure | reserve disclosure, redemption route, issuer terms, official contract address |
| PayPal/Venmo | consumer wallet surface, user UX, supported transfer policy | 사용자가 어느 chain으로 출금/입금할 수 있는지, reward/fee/limits가 무엇인지 |
| Public chain | token transfer, confirmation, address ownership | chainId, finality, gas, indexer, token standard, contract upgrade/freeze behavior |
| Merchant/payment app | checkout, crediting, refund, settlement, ledger | payment intent, original transaction key, refund asset, settlement currency |
| Vendor | custody, KYT, accounting, tax, wallet infrastructure | PYUSD 지원 여부, chain별 coverage, alerting, reconciliation |
이 표를 그리지 않으면 "PayPal이니까 결제가 된다"는 막연한 문장으로 끝난다. 실제 구현은 어떤 chain의 어떤 contract에서 온 transfer를 몇 confirmation 뒤에 입금 처리할지, merchant에게 PYUSD 그대로 정산할지 USD/USDC로 바꿔 정산할지까지 정해야 한다.
2. USDC와 비교할 때 기능보다 운영 질문을 본다
| 항목 | USDC | PYUSD |
|---|---|---|
| 발행자 | Circle | Paxos |
| 결제 유통 | wallets, exchanges, payment apps | PayPal/Venmo/eligible exchanges 포함 |
| 투명성 | Circle transparency | Paxos monthly reports와 attestation |
| 개발자 관점 | contract address, CCTP, Circle product | chain support, PayPal/Paxos redemption route |
| 주요 질문 | native/bridged 구분 | PayPal ecosystem과 onchain liquidity 연결 |
이 비교는 market share 비교가 아니다. USDC는 CCTP, Circle API, 여러 chain의 native issuance 같은 개발자 surface가 강하다. PYUSD는 PayPal consumer surface와 Paxos issuer 구조가 결제 narrative의 중심이다. 그래서 PYUSD를 붙일 때는 "DeFi collateral로 충분히 깊은가"와 "consumer payment/refund에 자연스러운가"를 따로 평가해야 한다.
3. 지원 체인은 source register로 관리한다
PYUSD의 지원 네트워크는 변한다. 2026-05-14 기준으로 Paxos/PayPal 공식 자료를 다시 확인하면 Ethereum, Solana, Arbitrum 관련 설명이 보이고, PayPal legal/help 문서에서는 지원 체인 목록이 별도로 갱신된다. 그러므로 강의와 제품 문서는 체인 목록을 암기하지 말고 source register로 관리해야 한다.
| 필드 | 기록할 내용 |
|---|---|
network | Ethereum, Solana, Arbitrum 등 실제 지원 체인 |
tokenAddressSource | Paxos/PayPal 공식 문서, explorer link, GitHub 등 |
lastVerifiedAt | 지원 여부와 contract address를 마지막 확인한 날짜 |
tokenStandard | ERC-20, SPL/Token-2022 여부 등 chain별 처리 차이 |
depositPolicy | 몇 confirmation/finality 뒤 credit할지 |
withdrawalPolicy | 출금 가능 여부, 지원 지갑, chain mismatch 방지 |
enableCondition | indexer, KYT, custody, accounting vendor가 모두 지원되는지 |
특히 L2나 신규 chain은 비용이 낮고 UX가 좋을 수 있지만, finality, withdrawal route, bridge/liquidity, vendor coverage가 별도 문제다. "공식 지원"과 "우리 서비스가 운영 가능"은 같은 말이 아니다.
4. Reserve report는 결제 dashboard의 출처가 된다
Paxos는 PYUSD reserve assets에 대한 월별 reserve report와 third-party attestation을 공개한다. 이 자료는 onchain totalSupply와 같은 값이 아니다. Offchain reserve composition과 reporting date를 보여주는 disclosure source다.
| 항목 | dashboard에 남길 내용 |
|---|---|
| Reserve report URL | 최신 report 링크와 보고 기준일 |
| Attestation provider | 독립 회계법인, 적용 기준, 게시일 |
| Outstanding supply | report 기준 liability와 onchain supply 비교 방식 |
| Reporting delay | 월말 이후 게시까지의 지연 |
| Product policy | report stale 또는 issuer notice 발생 시 checkout/settlement 제한 |
학습자는 여기서 "attestation이 있으니 실시간 reserve가 보장된다"는 말을 피해야 한다. Attestation은 기준일이 있는 보고 자료다. Checkout dashboard는 해당 자료의 최신성, 적용 범위, 운영 정책을 함께 보여줘야 한다.
5. 결제 제품에서의 장점과 리스크를 함께 쓴다
| 장점 | 리스크 |
|---|---|
| consumer payment brand와 연결 | onchain DeFi liquidity가 USDC보다 얕을 수 있음 |
| regulated issuer 구조 | chain별 지원 범위 확인 필요 |
| payment narrative가 명확 | merchant accounting route를 따로 설계해야 함 |
| L2 결제 비용 절감 가능 | L2 finality와 withdrawal policy 필요 |
장점은 product adoption의 언어이고, 리스크는 운영 설계의 언어다. 둘 중 하나만 쓰면 강의 자료가 홍보문이나 경고문으로 기울어진다. 결제형 stablecoin 강의는 항상 "사용자가 좋은 UX를 느끼는 지점"과 "운영자가 원장에 남겨야 할 지점"을 같이 보여줘야 한다.
6. Checkout/refund 상태를 먼저 설계한다
PYUSD류 결제형 stablecoin을 checkout에 붙일 때 가장 먼저 정해야 할 것은 refund다. 결제는 성공했지만 merchant settlement 전에 환불되는 경우, merchant에게 이미 USD로 정산한 뒤 환불되는 경우, 사용자가 원래 결제한 chain이 더 이상 지원되지 않는 경우가 모두 다르다.
| 상태 | 원장에 필요한 키 |
|---|---|
OnchainTransferSeen | chain, tokenAddress, txHash, logIndex, from, to, amount |
Credited | paymentIntentId, creditedAmount, confirmationCount, creditedAt |
SettlementPending | merchantId, settlementAsset, settlementRoute, feePolicy |
Settled | settlementBatchId, settlementTxOrFiatRef, exchangeRate if converted |
RefundRequested | originalPaymentIntentId, refundReason, refundAssetPolicy |
RefundConfirmed | refundTxHash 또는 fiat payout reference, refundedAmount, residual fee |
이 모델을 만들면 "PYUSD를 받는다"는 문장이 실제 제품 요구사항으로 바뀐다. 결제 수수료를 누가 부담하는지, partial refund가 가능한지, 원거래와 환불 거래를 어떻게 연결하는지가 분명해진다.
7. Vendor readiness를 통과해야 enable한다
| 영역 | 질문 |
|---|---|
| Wallet/custody | 사용자가 PYUSD를 입금할 주소와 chain mismatch 방지 UI가 있는가? |
| Indexer | chain별 transfer event, decimals, token standard를 안정적으로 읽는가? |
| KYT/compliance | PYUSD와 해당 chain의 address risk screening을 지원하는가? |
| Accounting/tax | merchant settlement, refund, conversion fee를 회계 이벤트로 분리하는가? |
| Liquidity/conversion | merchant가 PYUSD를 그대로 보유하지 않을 때 USD/USDC 전환 route가 있는가? |
| Incident response | issuer notice, reserve report delay, chain outage 때 checkout을 끄는 runbook이 있는가? |
코드로 확인하기
위 설계 결정을 코드에서 확인한다. 상태, 서명, 원장 이동, 실패 처리가 어디에 놓이는지 따라 읽으면 앞의 모델이 실제 구현 경계로 내려온다.
백엔드PYUSD source register (Ethereum + Solana 멀티체인)
PYUSD는 Ethereum, Solana, Arbitrum 등 여러 체인에서 발행되며 표준이 다르다. chain별 token standard와 검증 방식을 분리한다.
type PyusdRegistry = { chain: "ethereum" | "solana" | "arbitrum"; tokenStandard: "erc20" | "spl"; address: string; // EVM hex 또는 SPL mint decimals: number; vendorCoverage: Array<"paxos-attestation" | "kyt-provider-a" | "settlement-route">; lastVerifiedAt: string; sourceUrl: string;};export const PYUSD_REGISTRY: PyusdRegistry[] = [ { chain: "ethereum", tokenStandard: "erc20", address: "0x6c3ea9036406852006290770BEdFcAbA0e23A0e8", decimals: 6, vendorCoverage: ["paxos-attestation", "kyt-provider-a", "settlement-route"], lastVerifiedAt: "2026-05-14", sourceUrl: "https://docs.paxos.com/stablecoin/pyusd" }, { chain: "solana", tokenStandard: "spl", address: "2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo", decimals: 6, vendorCoverage: ["paxos-attestation", "settlement-route"], lastVerifiedAt: "2026-05-14", sourceUrl: "https://docs.paxos.com/stablecoin/pyusd" }];인덱서EVM Transfer 와 Solana SPL transfer 분리 처리
같은 PYUSD 결제여도 chain마다 이벤트 모델이 다르다. unified 결제 상태로 합쳐오려면 indexer 측이 둘 다 처리할 수 있어야 한다.
// EVM 측import { parseAbi } from "viem";const evmAbi = parseAbi(["event Transfer(address indexed from, address indexed to, uint256 value)"]);// Solana 측 — @solana/web3.js 와 SPL token program 활용 (의사 코드)async function watchSolanaPyusd(connection: any, mint: string, merchantAta: string) { connection.onProgramAccountChange(SPL_TOKEN_PROGRAM, async (info: any) => { const ata = info.accountId.toBase58(); if (ata !== merchantAta) return; const parsed = info.accountInfo.data.parsed.info; await onPyusdReceived({ chain: "solana", to: parsed.owner, amount: BigInt(parsed.tokenAmount.amount), decimals: parsed.tokenAmount.decimals, signature: info.transaction?.signatures?.[0] }); });}백엔드결제 → fiat 정산 변환 routing 결정
merchant가 PYUSD를 직접 보유하지 않을 때 conversion route 선택. 실시간 쿼우터 + slippage + fee를 한 함수로.
type ConversionRoute = "paxos-direct-redeem" | "exchange-otc" | "onchain-dex";export async function pickConversionRoute(args: { amountUsd: number; chain: "ethereum" | "solana"; merchantPreference: "speed" | "cost" | "compliance";}): Promise<{ route: ConversionRoute; estimatedFeeBps: number; etaSeconds: number }> { if (args.amountUsd > 250_000 && args.merchantPreference !== "speed") { return { route: "paxos-direct-redeem", estimatedFeeBps: 5, etaSeconds: 86400 }; } if (args.merchantPreference === "compliance") { return { route: "exchange-otc", estimatedFeeBps: 10, etaSeconds: 3600 }; } return { route: "onchain-dex", estimatedFeeBps: 30, etaSeconds: 60 };}강의 포인트
| 관점 | 강의 중 확인할 질문 | 학습 후 남길 증거 |
|---|---|---|
| Actor | Paxos, PayPal, chain, merchant의 책임이 어디서 갈라지는가? | actor 책임표 |
| Chain support | 공식 지원 체인과 우리 enable 조건을 분리했는가? | source register |
| Payment UX | consumer payment와 merchant settlement가 같은 자산으로 끝나는가? | settlement policy |
| Refund | 결제 원거래와 환불 거래를 어떤 키로 연결하는가? | checkout/refund 상태표 |
실무 예시
백엔드[INDEXER] 상황: merchant가 "PayPal 사용자가 PYUSD로 결제하고, 우리는 USD로 정산받고 싶다"고 요청했다. 이 요청은 토큰 allowlist가 아니라 운영 설계 과제다.
| 결정 항목 | 선택지 | 강의에서 요구하는 산출물 |
|---|---|---|
| 결제 수단 | PYUSD on Ethereum/Solana/Arbitrum 중 무엇을 받을지 | 공식 주소와 vendor coverage 표 |
| 정산 자산 | PYUSD, USDC, fiat USD 중 무엇으로 정산할지 | merchant settlement policy |
| 환불 자산 | 원래 chain의 PYUSD, 다른 stablecoin, fiat refund | refund policy와 fee 부담 주체 |
| Reserve/issuer 상태 | report stale, issuer notice, chain outage 때 어떻게 할지 | pause/warning runbook |
| 소비자 안내 | 결제 완료, pending, refund submitted를 어떻게 보여줄지 | user-facing status copy |
이 표가 있으면 개발 작업도 분명해진다. 결제 감지는 txHash만 저장하지 않고 paymentIntentId, chain, tokenAddress, confirmedAt, settlementRoute, refundPolicy를 함께 저장한다. 나중에 merchant가 USD 정산을 받았는지, 사용자가 PYUSD 환불을 받았는지, 수수료가 누구에게 부과됐는지 추적할 수 있다.
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| PayPal 이름이 붙었으니 PayPal이 issuer라고 생각한다. | PYUSD는 Paxos가 발행한다. PayPal surface와 issuer 책임을 분리한다. |
| 지원 체인 목록을 한 번 적어두면 끝이라고 본다. | 공식 문서와 legal/help 문서가 갱신될 수 있으므로 source register와 확인일이 필요하다. |
| 결제 성공만 구현하고 refund를 나중에 설계한다. | 결제형 stablecoin의 핵심 UX는 refund, partial refund, merchant settlement 후 환불이다. |
| DeFi liquidity 기준으로만 평가한다. | consumer payment, PayPal/Venmo UX, reserve disclosure, merchant accounting을 함께 본다. |
실습 과제
- 운영PYUSD actor 책임표 만들기: Paxos, PayPal/Venmo, public chain, wallet/custody/KYT vendor, merchant가 각각 맡는 책임과 장애 시 확인할 출처를 표로 정리한다.
- 백엔드PYUSD checkout/refund 상태표 작성하기: 결제 감지, confirmation, merchant settlement, refund, partial refund, failed refund, chargeback-like dispute를 상태와 원장 키로 설계한다.
- 백엔드지원 체인 source register 만들기: Ethereum, Solana, Arbitrum 등 PYUSD 지원 체인을 공식 출처, contract address/source URL, 마지막 확인일, enable 조건으로 관리하는 표를 만든다.
완료 기준
- 결제형 요구와 DeFi 요구를 분리했다.
- refund 모델을 설계했다.
- 운영 주체별 책임을 기록했다.
- 지원 체인과 contract address를 공식 출처 기준 source register로 관리했다.
근거 자료
- PYUSD 결제형 스테이블코인: 01-스테이블코인/11-PYUSD-결제형-스테이블코인.md
- Paxos Docs: PYUSD Overview: https://docs.paxos.com/stablecoin/pyusd
- Paxos Docs: Integrate with PYUSD on Ethereum: https://docs.paxos.com/stablecoin/integrate-pyusd
- Paxos: PYUSD Transparency Reports: https://www.paxos.com/pyusd-transparency/
- PayPal Developer Blog: PYUSD on Arbitrum: https://developer.paypal.com/community/blog/pyusd-on-arbitrum
- PayPal Help: What is PayPal USD?: https://www.paypal.com/us/cshelp/article/what-is-paypal-usd-pyusd-help1005
- PayPal Cryptocurrency Terms and Conditions: https://www.paypal.com/us/legalhub/paypal/cryptocurrencies-tnc