DOCSEARCHbyAlgolia
Submit Docs

Coinbac Merchant API

website·Indexed 30 days ago

https://doc.coinbac.vip

HTTP RESTful interface for merchants to integrate cryptocurrency payment gateway services. Features include payment and recharge processing, subscription management, withdrawal order querying, and sub-contract wallet handling. Includes specialized signer APIs for EVM and TVM chain operations such as sweeping, rebalancing, and transaction signing. Version 1.0.20.

Tokens
46.5K
Snippets
128
Records
366
Agent score
49%

What's inside Coinbac

  1. Overview of the Coinbac Payment Process

    The Coinbac payment flow allows merchants to generate payment requests that users complete via payment links or wallet addresses. The system automatically confirms payments and notifies the merchant via a callback.

    Workflow: Merchant calls createPaymentOrder $\rightarrow$ Receives payment link/sub-contract address $\rightarrow$ User completes payment $\rightarrow$ Coinbac sends callback to notifyUrl $\rightarrow$ Merchant confirms order.

  2. Overview of Cross-Chain Swap Capabilities

    The admin console includes a built-in cross-chain swap tool that allows asset transfers between major blockchains without external bridge integration. It supports USDT and other mainstream stablecoins and native coins across TRON (TRC20), Ethereum (ERC20), and BSC (BEP20). Funds are sourced from the Hot Wallet (Finance) account, and fees are integrated into the real-time swap rate. Settlement typically occurs within minutes, depending on network congestion.

  3. Overview of Coinbac non-custodial payment protocol

    Coinbac is a non-custodial digital asset payment protocol that enables Web2 companies to integrate Web3-based payment channels. It uses smart contracts for fund custody instead of centralized institutions, ensuring that all transactions are confirmed on-chain and that user funds remain secure even if the platform servers fail. The platform provides payment collection and deposit/withdrawal services, allowing merchants to maintain full control over their funds.

  4. Coinbac Merchant API Overview

    The Merchant API (Version 1.0.20) is an HTTP RESTful interface provided by Coinbac. It allows merchants to programmatically implement core financial functions including user recharge, withdrawal, payment, subscription, and refund.

  5. Query on-chain transaction information by hash

    Use the /transaction/info endpoint to retrieve detailed information about a specific transaction on the blockchain. This is a GET request that requires a transaction hash to identify the record.
    GET /transaction/info

  6. Configure multi-merchant and enterprise features

    Coinbac supports multi-merchant onboarding, allowing for independent backends and payment configurations for different merchants. For KYT (Know Your Transaction) requirements, Coinbac can provide recommendations for third-party KYT companies.

  7. Understand Secure Self-Custody architecture and requirements

    Secure self-custody is a smart contract-based approach to managing crypto assets that removes reliance on third-party servers and prevents single points of failure. A valid secure self-custody solution must meet two criteria:

    1. Merchant Ownership: All services and nodes must be fully owned by the merchant with ultimate authority.
    2. Fault Tolerance: The loss of any single node or server authority must not result in financial loss. This is achieved by separating the system into two modules:
      • Service Module: Handles operational logic (e.g., Web2 servers). If this module is compromised, it should not lead to asset loss.
      • Asset Custody Module: Implemented via smart contracts and managed by a multi-signature system. Assets remain recoverable by senior administrators even if all server authorities are compromised.

  8. Understand the Guardian security component

    The Guardian is a security service component deployed in the backend or on an independent server. It acts as a secondary validation layer for on-chain transfer requests or critical multi-signature operations originating from a merchant system. Its core mechanism involves independently generating a signature using the same parameters as the initial request and comparing it to the original signature; the on-chain execution is only permitted if the signatures match and permissions are valid. This prevents data tampering, forged signatures, and unauthorized operations.

  9. Coinbac Contract Architecture Reference

    The following components define the fund management architecture:

    • Sub-contract Factory Template: A standardized generator bound to a cold contract that ensures all sub-accounts flow to the same treasury.
    • Sub-contract Address: A pre-generated payment account number (initially an EOA).
    • Sub-contract: An activated, on-chain smart contract established after the first fund sweep.
    • Cold Contract: The merchant's secure headquarters main treasury.
    • Hot Contract: The merchant's daily operational account for expenditures.

  10. Implement asset control using the Self-Custody Model

    The Self-Custody Model utilizes a tiered architecture of sub-contracts, hot contracts, and cold contracts. This design ensures that merchants maintain full control over their assets, preventing the service provider from accessing merchant funds.

  11. Understand Tag Address allocation and management

    Tag Address allows merchants to categorize wallet addresses into pools. When a payment order is created with a specific tagId, the system automatically assigns a receiving address based on these rules:

    1. If an available address exists under the specified tag, the system prioritizes reusing it.
    2. If all addresses under the tag are occupied, the system automatically creates a new address and assigns it to that tag.

    This mechanism enables address categorization, reuse, and automatic expansion for merchants managing large volumes of receiving addresses.

  12. Manage wallet addresses using Tag Address

    Tag Address allows merchants to categorize and manage wallet addresses by assigning them to specific tags. When creating a payment order, specifying a tagId ensures the system assigns a receiving address from the corresponding tagged address pool based on the following allocation rules:

    1. Reuse: If an available address exists under the specified tag, the system prioritizes reusing it.
    2. Automatic Creation: If all addresses under the tag are currently occupied, the system automatically creates a new address.
    3. Automatic Assignment: Any newly created address is automatically assigned to the same tag.

    This mechanism is designed for scenarios requiring address categorization, reuse, and automatic expansion when managing a large volume of receiving addresses.