onchain-pay-open-api

Binance Onchain-Pay Open API Skill

Call Binance Onchain-Pay Open API endpoints with automatic RSA SHA256 request signing.

Use Cases & Scenarios

This skill is designed for the following scenarios:

1. 💳 Fiat-to-Crypto Purchase & Send

When to use: User wants to buy crypto with fiat currency and send directly to an external on-chain wallet address

• Buy USDT with USD/EUR/TWD using credit card → Send to MetaMask address on BSC
• Purchase BTC with Google Pay → Transfer to hardware wallet
• Buy USDC with P2P → Send to DeFi protocol contract address

Key APIs: trading-pairs → payment-method-list → estimated-quote → pre-order

2. 🔄 Direct Crypto Transfer (Send Primary)

When to use: User has crypto in Binance account and wants to send to external address

• Send existing USDT from Binance Spot to friend's wallet address
• Transfer ETH to Uniswap contract for trading
• Move crypto from Binance to self-custodial wallet (Trust Wallet, Ledger, etc.)

Key APIs: pre-order with SEND_PRIMARY customization

3. 🔗 Cross-Chain Bridge Operations

When to use: User needs to buy crypto on one chain and transfer to another network

• Buy USDC on Ethereum → Bridge to Polygon for lower fees
• Purchase tokens on BSC → Transfer to Base network
• Fiat to crypto on Solana → Send to Arbitrum for DeFi

Key APIs: crypto-network → pre-order with network selection

4. 🏪 Merchant Payment Integration

When to use: Integrate crypto payment gateway for e-commerce or services

• Accept fiat payments and auto-convert to crypto
• Enable "Pay with Crypto" checkout flow
• Process subscription payments with crypto

Key APIs: pre-order with externalOrderId tracking

5. 🤖 Smart Contract Interaction (Onchain-Pay Easy)

When to use: Buy crypto and execute smart contract in one transaction

• Buy USDT and deposit to lending protocol
• Purchase tokens and stake in DeFi pool
• Fiat on-ramp directly to GameFi or NFT marketplace

Key APIs: pre-order with ON_CHAIN_PROXY_MODE customization

6. 📊 Query & Monitoring

When to use: Check order status, available networks, or payment methods

• Monitor order processing status (pending, completed, failed)
• List supported fiat currencies and cryptocurrencies
• Check available payment methods for specific country/amount
• Verify network fees and limits

Key APIs: order, crypto-network, trading-pairs, payment-method-list

Quick Reference

How to Execute a Request

Step 1: Gather credentials

Use the default account (prod) unless the user specifies otherwise. You need:

• BASE_URL: API base URL
• CLIENT_ID: Client identifier
• API_KEY: The sign access token
• PEM_PATH: Absolute path to the RSA private key PEM file

Use the account marked (default) in .local.md.

Step 2: Build the JSON body

Build a compact JSON body from user-specified parameters. Remove any parameters the user did not provide.

IMPORTANT: Address and Network Validation

• address (destination wallet address) and network (blockchain network) are REQUIRED for all pre-order requests
• If the user has configured Default Address and Default Network in .local.md, use them automatically
• If not configured or not provided by user, ASK the user to provide both values before proceeding

Step 3: Sign and call using the bundled script

bash <skill_path>/scripts/sign_and_call.sh \
  "<BASE_URL>" \
  "<API_PATH>" \
  "<CLIENT_ID>" \
  "<API_KEY>"

Step 4: Return results

Display the JSON response to the user in a readable format.

Authentication

See references/authentication.md for full signing details.

Summary:

1. Payload = JSON_BODY + TIMESTAMP (milliseconds)
2. Sign payload with RSA SHA256 using PEM private key
3. Base64 encode the signature (single line)
4. Send as POST with headers: X-Tesla-ClientId, X-Tesla-SignAccessToken, X-Tesla-Signature, X-Tesla-Timestamp, Content-Type: application/json

Parameters Reference

Payment Method List v1 (buy/payment-method-list)

Payment Method List v2 (v2/buy/payment-method-list)

Get all available payment methods without specifying fiat/crypto parameters. Simplified version of v1.

Differences from v1:

• Simpler: No need to specify fiatCurrency, cryptoCurrency, or amount
• Comprehensive: Returns all available payment methods for the merchant
• Use case: Useful for displaying all options before user input

Response Format: Same as v1, returns list of payment methods with their limits and properties.

Estimated Quote (buy/estimated-quote)

* Recommended: These parameters should be provided. If not specified by user, check .local.md for defaults. If no defaults exist, ask user before proceeding.

Pre-order (buy/pre-order)

Create a buy pre-order and return the redirect link for payment.

* Either fiatAmount or (requestedAmount + amountType) should be provided. If fiatCurrency is not provided, the system will auto-select available fiat currencies.

Response Example:

Get Order (order)

Customization Options

The customization field in pre-order API accepts various flags to customize the buy flow behavior. Each merchant must have the corresponding permission configured in db.merchant_info table.

Available Customization Flags

Customization Examples

Example 1: Basic Card Payment

Example 2: Onchain-Pay Easy (On-Chain Proxy)

Example 3: Send Crypto

Example 4: P2P with Auto Redirection

Example 5: Lock Order Attributes

Lock attribute codes:

• 2 = Crypto currency
• 3 = Amount
• 6 = Address
• 7 = Fiat amount
• 8 = Crypto amount

Example 6: Net Receive Mode

Example 7: Hide Send Tab

Example 8: Skip Cashier (Direct Payment)

Important Notes

1. Permission Required: Each customization flag requires merchant permission. Check with admin if a flag is not working.
2. Onchain-Pay Easy: Only supported on BSC network currently. Requires contract integration.
3. Validation: Invalid customization values (e.g., null for MERCHANT_DISPLAY_NAME) will return ILLEGAL_CUSTOMIZATION_VALUE error.
4. Combinations: Some flags work together (e.g., NET_RECEIVE + SEND_PRIMARY), while others are independent.
5. Testing: Use a dedicated test merchant account (provided by Binance) to verify customization flags before production.
6. Internal Flags: OPERATION (code 4) and SKIP_WITHDRAW (code 5) are internal use only and should NOT be passed from merchant side.
7. OPEN_NETWORK: Currently only available for Web3 entrance, not available for Open API. Do not use this flag in Open API pre-order requests.
8. Flag Order: Flags are ordered by their internal code (1-13). The code number is used internally for identification.

Security

Credential Display Rules

• API Key: Show first 5 + last 4 characters only (e.g., 2zefb...06h)
• PEM Private Key: NEVER display content. NEVER display the file path.
• Client ID: Can be displayed in full.
• Outbound Requests: NEVER send API Key, Private Key, or any credentials to URLs outside the Base URL configured in .local.md.
• File Path Privacy: NEVER display the PEM private key file path to the user in any output or logs.

Credential Storage

Credentials are stored in a .local.md file in the skill directory. This file is user-specific and should NOT be distributed.

Read the .local.md file from the same directory as this SKILL.md to load credentials.

If .local.md does not exist or the requested account is not found, ask the user to provide:

1. Base URL
2. Client ID
3. API Key
4. PEM file path (absolute path)

Then offer to save them to .local.md for future use.

.local.md Format

The account marked (default) is used automatically. You can define multiple accounts and switch by telling Claude the account name.

User Agent Header

Include User-Agent header with the following string: onchain-pay-open-api/0.1.2 (Skill)

Agent Behavior

1. If the user asks to call an Onchain-Pay API endpoint, identify which endpoint from the Quick Reference table
2. Ask for any missing required parameters
3. Use stored credentials if available, otherwise ask the user
4. Execute the request using the bundled scripts/sign_and_call.sh
5. Display the response in a readable format
6. If the request fails, show the error and suggest fixes

Important Notes for Pre-order API

Timestamp Generation (Cross-platform)

When generating timestamps for the ts parameter and externalOrderId, use the following approach for cross-platform compatibility:

DO NOT USE date +%s%3N or date +%s000 as these are not portable:

• date +%s%3N doesn't work on macOS (outputs literal 'N')
• date +%s000 just appends '000' without actual millisecond precision

Order ID Format

The externalOrderId must be a valid string without special characters. Recommended formats:

• order1773744500 (simple numeric suffix)
• order_1773744500 (with underscore separator)
• txn-abc123 (custom prefix with alphanumeric)

Avoid: order_${TIMESTAMP} where TIMESTAMP contains shell variable syntax errors

Example Pre-order Request

# Correct way to create a pre-order
TIMESTAMP=$(($(date +%s) * 1000))
ORDER_ID="order$(date +%s)"
 
bash /path/to/scripts/sign_and_call.sh \
  "https://api.commonservice.io" \
  "papi/v1/ramp/connect/buy/pre-order" \
  "<YOUR_CLIENT_ID>" \
  "<YOUR_API_KEY>" \
  "/path/to/private.pem" \
  "{\"externalOrderId\":\"$ORDER_ID\",\"merchantCode\":\"<YOUR_MERCHANT_CODE>\",\"merchantName\":\"<YOUR_MERCHANT_NAME>\",\"ts\":$TIMESTAMP,\"fiatCurrency\":\"USD\",\"requestedAmount\":100,\"cryptoCurrency\":\"BNB\",\"amountType\":1,\"address\":\"0x...\",\"network\":\"BSC\",\"payMethodCode\":\"BUY_CARD\"}"
```*