# Introduction OMY Payments is the first cryptocurrency payments processor powered by DeFi infrastructure. The project is based on the Chainspot protocol's technological solution, operational since 2021, and funded by some of the top DeFi industry angels and funds: \ Blockchain Founders Fund, Michael Egorov (Curve), Anton Bukov (1Inch), Funders VC, Vadim Koleoshkin (Zerion), Cointelegraph, Andrey Nayman (Magic Square), Asymmetry Capital, and Boris Povar (CrossCurve), Qwerty Labs, Vasily Sumanov. Accept cryptocurrency payments to expand your potential customer base and save on cross-border transactions using the best DeFi technologies—low exchange fees, access to yield-generating protocols, as well as security and transparency of fund movements without intermediaries like centralized crypto exchanges. ### Jump right in
Why accept cryptoBoost your profits/pages/CyH2xJQs9yWJ1S8BYNav
What are cryptocurrenciesLearn the basics/pages/7aUFmnCMx9m4smGncsXL
IntegrationFast no-code integration/pages/JjjojIyKxaiBPzzLwvtg
# What are cryptocurrencies ### Introduction Cryptocurrencies have revolutionized the financial world by offering a decentralized, secure, and transparent way to store and transfer value. Unlike traditional fiat currencies issued by governments and controlled by central banks, cryptocurrencies operate on decentralized networks using blockchain technology. This article will explore the origins, types, advantages, and real-world applications of cryptocurrencies, providing a detailed overview of this digital financial ecosystem. ### The Origin of Cryptocurrencies The concept of digital currency dates back to the early 1990s, but the first successful cryptocurrency, Bitcoin, was introduced in 2008 by an anonymous entity known as Satoshi Nakamoto. The goal was to create a peer-to-peer electronic cash system that would eliminate the need for intermediaries like banks. Bitcoin operates on a blockchain, a distributed ledger that records all transactions publicly. This transparency ensures security and prevents double-spending, making it a groundbreaking innovation in the financial sector. ### How Cryptocurrencies Work Cryptocurrencies function on decentralized networks, typically using blockchain technology. A blockchain is a series of blocks containing transaction data that are verified and added to the chain through a process called mining or validation. #### Key Features of Cryptocurrencies: 1. **Decentralization** – No single authority controls cryptocurrencies; instead, they operate on a distributed network of computers. 2. **Security** – Cryptographic techniques secure transactions, making them tamper-resistant. 3. **Transparency** – Blockchain technology allows anyone to verify transactions in real time. 4. **Anonymity** – While transactions are public, users' identities remain pseudonymous. ### Types of Cryptocurrencies Since Bitcoin’s inception, thousands of alternative cryptocurrencies (altcoins) have been developed, each serving different purposes. #### 1. **Bitcoin (BTC)** Bitcoin remains the most valuable and widely used cryptocurrency. It is often referred to as "digital gold" due to its store-of-value properties. #### 2. **Ethereum (ETH)** Ethereum introduced smart contracts—self-executing contracts with predefined rules—enabling the creation of decentralized applications (dApps). #### 3. **Stablecoins (USDT, USDC, DAI)** Stablecoins are pegged to stable assets like the US dollar to minimize volatility. These are often used for transactions and remittances. #### 4. **Privacy Coins (Monero, Zcash)** Privacy-focused cryptocurrencies offer enhanced anonymity by obscuring transaction details. {% hint style="info" %} Please note that in some countries, these currencies may be considered a means of money laundering. \ OMY Payments conducts free transaction screening to ensure your financial and legal security. {% endhint %} #### 5. **Utility Tokens (BNB, UNI, LINK)** These tokens provide access to specific blockchain-based services or ecosystems. ### Advantages of Cryptocurrencies #### 1. **Lower Transaction Fees** Traditional financial transactions often involve high fees from banks and payment processors. Cryptocurrencies eliminate intermediaries, reducing costs. #### 2. **Financial Inclusion** Cryptocurrencies provide access to financial services for unbanked populations in developing regions. #### 3. **Borderless Transactions** Unlike traditional banking systems that impose restrictions on international transfers, cryptocurrencies allow seamless global transactions. #### 4. **Security and Fraud Prevention** Blockchain technology ensures that transactions are immutable, reducing the risk of fraud and chargebacks. ### Real-World Use Cases #### **1. Online Payments** Companies like Microsoft and Tesla accept Bitcoin as a form of payment, demonstrating mainstream adoption. #### **2. International Remittances** Cryptocurrencies enable cheaper and faster cross-border remittances compared to traditional banks. #### **3. Decentralized Finance (DeFi)** DeFi platforms allow users to earn interest, borrow, and lend assets without intermediaries. #### **4. NFTs and Digital Assets** Non-fungible tokens (NFTs) have created a new digital economy for artists, musicians, and gamers, enabling direct ownership of digital assets. ### Challenges and Risks #### 1. **Regulatory Uncertainty** Governments worldwide are still developing regulations for cryptocurrency use, leading to legal challenges in certain jurisdictions. {% hint style="success" %} Stay in the legally safe zone with OMY Payments! All transactions, both incoming and outgoing, undergo AML checks to ensure your financial security. {% endhint %} #### 2. **Market Volatility** Cryptocurrency prices can fluctuate significantly, making them a risky investment. {% hint style="success" %} Eliminate volatility risks with the auto-conversion feature, seamlessly converting assets into your base currency. Ensure the best exchange rates with OMY's unique infrastructure, aggregating over $7B in liquidity across 45+ blockchains. {% endhint %} #### 3. **Security Threats** While blockchain technology is secure, individual users are vulnerable to hacking, scams, and phishing attacks. {% hint style="success" %} You and your clients are safe with OMY Payments — we undergo regular security audits by top industry firms and provide modern protection tools, including 2FA, financial passwords, whitelists, and more. {% endhint %} ### The Future of Cryptocurrencies With growing institutional adoption, government interest, and technological advancements, cryptocurrencies are set to play a significant role in the global financial system. Central banks are also exploring digital currencies (CBDCs) as an alternative to traditional cash, further legitimizing the industry. ### Conclusion Cryptocurrencies represent a paradigm shift in how we perceive and interact with money. By providing decentralized, secure, and borderless transactions, they offer numerous benefits over traditional financial systems. While challenges exist, continued innovation and regulatory clarity will likely shape the future of digital assets, making them an integral part of the global economy. # Why accept crypto Embracing Digital Transactions As technology advances, businesses are looking for innovative ways to process payments. Cryptocurrencies provide a decentralized and secure alternative to traditional payment methods, offering numerous benefits for merchants. This article explores why adopting cryptocurrency can be a game-changer for businesses looking to expand their payment options. ### Why Businesses Are Turning to Cryptocurrency Digital assets such as Bitcoin, Ethereum, and stablecoins are gaining popularity due to their efficiency and inclusivity. Companies that integrate crypto payments can access a global market and reduce dependency on conventional banking systems. #### Key Factors Driving Crypto Payment Adoption: 1. **Broader Market Reach** – Accepting crypto attracts international customers and tech-savvy consumers. 2. **No Middlemen** – Transactions occur directly between the buyer and seller, reducing reliance on banks. 3. **Blockchain Security** – Fraud and chargeback risks are minimized due to the transparency of decentralized ledgers.

market insights

### Advantages of Cryptocurrency Transactions #### 1. **Minimized Transaction Fees** Traditional credit card processing fees can be high, cutting into profit margins. Cryptocurrency payments reduce these costs by removing intermediary fees. #### 2. **Rapid Cross-Border Settlements** Bank transfers for international payments often take days to process. Cryptocurrency transactions can be completed within minutes, improving cash flow. #### 3. **Protection Against Fraud & Chargebacks** Unlike credit card payments, crypto transactions are irreversible, preventing fraudulent chargebacks. #### 4. **Enhancing Brand Image & Attracting New Customers** Offering crypto as a payment option can appeal to a younger, digitally inclined audience while positioning a brand as an innovator. #### 5. **Hedging Against Inflation & Economic Instability** Holding a portion of revenue in cryptocurrencies may serve as a hedge against the volatility of fiat currencies. ### Final Thoughts Cryptocurrency adoption presents businesses with opportunities to optimize payments, cut costs, and attract new customers. While challenges exist, leveraging reliable payment solutions and staying informed on regulations can facilitate seamless integration. As digital currencies become more ingrained in global commerce, accepting crypto could transition from an advantage to a necessity in the competitive market landscape. # Our products # Payment Gateway In today’s digital economy, businesses require efficient and secure methods to process payments. A payment gateway serves as a bridge between merchants and financial institutions, enabling seamless transactions. Our solution offers a robust payment processing system via API, along with CMS plugins for simplified integration. ### What is a Payment Gateway? A payment gateway is a technology that facilitates online transactions by securely transmitting payment details between customers, merchants, and financial institutions. It ensures that payments are processed swiftly while maintaining security and compliance standards. #### Key Functions of a Payment Gateway: * **Transaction Authorization:** Verifies payment details before approving transactions. * **Data Encryption:** Ensures sensitive financial information is securely transmitted. * **Integration with Merchant Systems:** Works with e-commerce platforms, websites, and mobile applications. * **Multi-Currency Support:** Allows businesses to accept payments from international customers. ### Our Payment Processing Solution We provide a cutting-edge payment processing solution via API, allowing businesses to integrate secure transactions into their platforms effortlessly. Our system is designed to support various payment methods, including credit cards, cryptocurrencies, and alternative digital payments. #### Benefits of Our API-Based Payment Processing: * **Scalability:** Easily adapts to growing business needs. * **Security & Compliance:** Follows industry security protocols for safe transactions. * **Customization:** Allows merchants to tailor the payment experience according to their needs. * **Fast Settlement:** Ensures quicker transaction processing and fund transfers. ### CMS Plugins for Easy Integration For businesses using content management systems (CMS), we offer dedicated plugins to simplify payment processing integration. These plugins allow merchants to enable secure transactions without extensive coding or technical expertise. #### Supported CMS Platforms: * WooCommerce * WordPress * Shopify * OpenCart * Ghost * Magento * Joomla ### Why Choose Our Payment Gateway? #### 1. **Seamless API Integration** Our API enables merchants to integrate payment processing into their systems with minimal effort, providing a smooth and user-friendly experience. #### 2. **Comprehensive Security Measures** We implement advanced encryption and fraud prevention mechanisms to ensure every transaction is secure and compliant with global standards. #### 3. **Multi-Payment Method Support** We offer businesses the ability to accept payments through various channels, including traditional credit cards and innovative digital currencies. #### 4. **Global Reach** Our system allows businesses to accept payments from customers worldwide, supporting multiple currencies and local payment methods. #### 5. **Reliable Customer Support** Our team provides 24/7 support to assist businesses in ensuring smooth transaction processing and resolving potential issues promptly. ### Conclusion A reliable payment gateway is essential for businesses looking to streamline transactions and offer secure payment options. Our payment processing solution, available via API and CMS plugins, provides businesses with a seamless, secure, and scalable payment experience. By integrating our gateway, merchants can optimize their transaction process and enhance customer satisfaction. # Earnings on deposit Our Earnings on Deposit solution provides merchants with an opportunity to earn passive income on their unused balances by leveraging decentralized finance (DeFi) protocols. This non-custodial approach ensures security and accessibility while generating returns on idle funds. ### How It Works Merchants often maintain balances that are not immediately needed for operational expenses. Instead of letting these funds sit idle, our system allows seamless allocation into yield-generating DeFi pools. This process is automated and transparent, ensuring merchants retain control of their funds while maximizing their earning potential. #### Key Features of Earnings on Deposit: * **Non-Custodial Approach:** Merchants maintain full control over their funds, with no third-party holding assets. * **Integration with DeFi Protocols:** Funds are allocated into trusted third-party DeFi liquidity pools to generate returns. * **Flexible Withdrawals:** Merchants can access their funds at any time without restrictions. * **Risk Management:** Diversified strategies minimize exposure to potential market volatility. ### Benefits for Merchants #### 1. **Passive Revenue Generation** By allocating idle balances into yield-bearing pools, merchants can create an additional revenue stream without actively managing investments. #### 2. **Secure and Transparent Transactions** Our platform ensures transactions are recorded on a transparent blockchain ledger, providing full visibility and security. #### 3. **Seamless Integration** Merchants can easily opt into the Earnings on Deposit program through our platform with minimal setup, making the process efficient and user-friendly. #### 4. **No Interference with Liquidity Needs** Funds remain accessible, allowing merchants to withdraw or reallocate them as needed, ensuring financial flexibility. ### How to Get Started #### Step 1: **Activate the Earnings on Deposit Feature** Merchants can enable this feature directly through their account dashboard. #### Step 2: **Select a Preferred DeFi Pool** Choose from a selection of vetted DeFi pools that align with the desired risk and reward preferences. #### Step 3: **Monitor and Manage Returns** Track earnings in real time and adjust allocations based on financial needs. #### Step 4: **Withdraw Anytime** Merchants can withdraw their funds instantly, ensuring no disruption to their business operations. ### Conclusion Earnings on Deposit is a powerful solution for businesses looking to maximize the utility of their idle funds. By leveraging secure and efficient DeFi protocols, merchants can generate additional revenue while maintaining full control over their assets. As financial technologies evolve, integrating such innovative strategies ensures that businesses remain competitive and financially optimized. # Manual Invoices #### Flexible Invoice Generation Businesses often need a simple and adaptable way to generate invoices. Our solution allows merchants to create invoices quickly and share them through multiple channels, ensuring seamless payment collection without complicated setups. #### Multiple Ways to Share Invoices Merchants can send invoices in a way that best suits their workflow and customer preferences: * **Email Delivery** – Send invoices directly to a customer's inbox with payment details. * **Payment Button** – Embed a button on a website or platform, enabling one-click payment. * **Direct Link Sharing** – Generate a payment link that can be sent via messenger, SMS, or any communication channel. #### Customizable Payment Requests Each invoice can be tailored to fit specific transaction needs: * Set exact amounts in the preferred currency. * Define due dates and payment instructions. * Include notes or additional information for clarity. #### Instant Payment Tracking All invoices come with real-time tracking, allowing merchants to monitor the payment status, see confirmations, and send reminders if needed. #### No Technical Expertise Required The system is designed for easy use without requiring technical knowledge, making it accessible to all businesses, regardless of their size or industry. #### Optimized for Recurring and One-Time Payments Whether collecting a single payment or setting up recurring billing, the flexible invoice system supports various payment structures, giving businesses the freedom to manage transactions efficiently. # Payment & Donation button #### Accept Payments Without Fixed Amounts Not every transaction requires a predefined price. Our Payment & Donation Button allows users to set their own payment amount, offering full flexibility for various use cases such as content monetization, crowdfunding, and charitable donations. #### Ideal for Creators, Charities, and Service Providers This solution is perfect for platforms and individuals who receive voluntary payments, including: * **Content Creators & Influencers** – Easily receive support from fans, similar to services like Patreon or Boosty. * **Non-Profit Organizations** – Accept donations seamlessly without predefined limits. * **Freelancers & Small Businesses** – Offer clients a way to pay what they feel is appropriate for services rendered. #### Multiple Payment Options Users can not only set their own amount but also choose their preferred payment method, supporting: * Pay crypto from centralized exchange (Binance, Huobi, Gate and others) or cold wallet; * Pay using web3 wallet: MetaMask, WalletConnect, Tronlink and others. #### Easy Integration & Sharing The Payment & Donation Button can be added effortlessly to: * Websites and blogs. * Social media profiles. * Messengers and emails through shareable links. #### Real-Time Payment Tracking All transactions can be monitored in real-time, providing full transparency and tracking capabilities for merchants and recipients. #### Simple, No-Code Setup No technical expertise is required to deploy this feature. A few simple steps allow merchants, creators, and charities to start accepting payments immediately, providing a frictionless experience for both payers and receivers. # Mass Payouts Send thousands of on-chain payments in one go—safely, predictably, and without writing code. Mass Payouts lets you disburse funds to a list of recipients (payroll, affiliate rewards, creator royalties, refunds, grants) in a single run, with clear fees and built-in safeguards against duplicate sends. {% hint style="info" %} EVM and Tron Networks are available currently. {% endhint %} #### How it works 1. **Prepare a list** of recipients and amounts (manually or by file upload). 2. **Choose the asset** you’ll pay out and review the quoted fees. 3. **Run the payout**—we execute the distribution on-chain and track every transfer. 4. **See results** in your dashboard with per-row statuses and an auditable transaction trail. #### Key features * **Bulk disbursement in minutes** — purpose-built for recurring or high-volume payouts. * **CSV/XLSX import & reusable lists** — handy for payroll and scheduled distributions. * **Idempotency & retries** — protects against double sends and transient network hiccups. * **Transparent fees** — a flat per-recipient handling fee plus actual network gas. * **End-to-end visibility** — run summaries, per-row receipts, and exportable reports. * **No-code or API** — operate fully from the dashboard, or integrate programmatically. #### Benefits for merchants * **Saves ops time** by replacing manual transfers and one-off invoices. * **Reduces errors** with validated inputs and duplicate-send protection. * **Scales smoothly** from dozens to thousands of recipients. * **Fits your stack** — start no-code, adopt API later for automation. #### How to get started 1. **Request access** to Mass Payouts for your workspace. 2. **Enable the assets** you plan to use in **Assets** and set your fees/wallets (see *Prerequisites*). 3. **Create your first list** in the **Mass Payouts** section and run a small test. 4. **Go live** and schedule or trigger payouts as needed from the dashboard or API. *Need activation or help choosing the right flow? Visit your dashboard to get started:* [*https://dashboard.omypayments.com/*](https://dashboard.omypayments.com/) # Swaps Swaps allow a merchant to exchange one crypto asset for another directly inside the platform.\ The main goal is to provide a fast, controlled conversion flow without manual work in external services. In the dashboard, this appears as a dedicated section with: * a swap creation form, * a confirmation screen, * a list of all swaps, * a swap details view with status and execution data. *** #### How a swap works The flow is built as a managed lifecycle, where each stage has a clear role. 1. **Request creation**\ The merchant selects the source asset, target asset, and amount.\ At this stage, the platform allows only assets and directions that are actually supported for this specific merchant. 2. **Preliminary calculation (estimate)**\ The platform calculates the expected outcome and shows terms before execution starts.\ This estimate is approximate, as market conditions, routing conditions, and network fees may change. 3. **Confirmation and amount reservation**\ After confirmation, the operation is locked in and the source amount is reserved immediately.\ This protects the process from balance changes between estimation and actual execution start. 4. **Route execution**\ The platform runs the swap using internal route selection logic.\ If several routes are available, it picks the one with the best expected outcome.\ For some cross-network directions, a specialized route may be used. 5. **Finalization and crediting**\ After execution is completed, the platform records the actual result and credits the target asset.\ This final credited value is treated as the swap result. *** #### What to understand about amounts The estimate and the final credited amount may differ. This is a normal part of swap business logic. * **The confirm-stage estimate is a quote, not a permanent fixed value.**\ At confirmation, the merchant sees the best available estimate at that moment. However, between confirmation and final execution, the request passes through processing stages and network confirmations. During that time, market conditions may shift. Because of this, the final value is determined by actual execution, not frozen forever at form time. * **The final result depends on the real execution route and its operational steps.**\ The same swap pair may be executed through different routes depending on liquidity and network constraints. Each route has its own execution profile and cost structure. The platform therefore finalizes the amount only after the real route is completed and all factual execution parameters are known. * **Fees are composed of multiple components.**\ The outcome is affected by a combination of factors: network costs, route-level operational costs, and the platform system fee. These are applied automatically in final settlement. The merchant receives an amount that reflects the real end-to-end cost of the operation under current conditions. *** #### Pre-execution checks Before execution starts, the platform validates key conditions. These checks prevent invalid or high-risk operations from entering processing. * **Asset pair availability for this merchant.**\ The platform verifies that selected assets are active in the merchant account and can be used in the chosen swap direction. This avoids cases where assets exist globally in the platform but are not available in the merchant’s current setup. * **Direction and network/token rule validation.**\ The platform validates that the selected “from/to” combination matches supported swap scenarios. If the direction is blocked by platform rules or infrastructure limitations, execution is stopped before launch and a clear error is returned. * **Available balance sufficiency check.**\ The system checks available balance, not only total balance. This is important because part of funds may already be reserved by other operations. If available funds are insufficient, the swap is rejected before execution, preventing downstream failures. * **Minimum amount threshold in USD equivalent.**\ Swaps have a minimum threshold to keep operations economically meaningful relative to network and routing costs. The entered amount is converted to USD equivalent and checked against this minimum. If it is below the threshold, the platform does not start execution and returns a clear reason. * **Target infrastructure readiness for crediting.**\ Before launch, the platform confirms it can safely receive and credit the resulting asset in the target network. This reduces the risk of partial scenarios where execution is initiated but result delivery cannot be finalized properly. *** #### Merchant-facing statuses The dashboard uses clear high-level statuses: * **New** - swap created and queued for processing, * **In progress** - execution is running, * **Finished** - swap completed and result credited, * **Rejected** - execution did not complete successfully and was rejected. Additional internal service sub-stages exist, but they are abstracted into clear external statuses for the merchant. *** #### What happens on failures The service is designed not to leave swaps in an undefined state.\ If a swap cannot be completed safely within allowed checks, it moves to rejected status and source funds are returned according to platform rules. This gives the merchant a predictable outcome: * either successful conversion with credited result, * or safe termination with rejection and refund. *** #### What the merchant sees in history The swap list is not only for tracking active operations, but also for financial history.\ Each entry includes key data: creation time, swapped assets, current status, and final outcome after execution.\ This makes swaps a transparent, controllable part of the merchant’s financial workflow inside the platform. # Gas manager #### What it is **Gas Manager** is an automatic service that tops up the native coin in the required network (for example, ETH, TRX, TON, etc.) on your payment addresses.\ Its purpose is simple: to prevent your operations from stopping due to insufficient “gas” #### Why it matters for clients If a payment address runs out of the network’s native coin, some operations may fail or be delayed.\ Gas Manager removes this operational burden from merchants and keeps balances at working levels automatically. #### How the service works (in simple terms) 1. The service regularly checks native-coin balances on your active payment addresses. 2. For each network, it compares the current balance with the auto top-up threshold. 3. If the balance is below the threshold, the service starts a top-up process. 4. The top-up is executed automatically, without manual actions from the merchant. 5. After sending, the service checks confirmations and completes the operation. 6. If confirmation is not received on the first check, the service performs automatic rechecks. #### What is charged during top-up Each auto top-up includes two parts: 1. **Top-up amount** (USD equivalent, configured per network). 2. **Gas Manager fee** (percentage of the top-up amount, configured per network). **Fee formula:**\ `Fee (USD) = Top-up amount (USD) × Fee (%) / 100` **Total debit:**\ `Total (USD) = Top-up amount (USD) + Fee (USD)` #### Important notes 1. If an address already has enough native balance, no top-up is performed. 2. If reserve liquidity is insufficient, top-up may not start or may be completed only partially. 3. When multiple addresses are processed, partial outcomes are possible: some addresses are topped up, others are not. 4. The final received amount in native coin may slightly differ due to market conditions and network costs at the time of execution. #### What is needed for stable operation 1. Gas Manager enabled and active for the merchant. 2. Sufficient reserve liquidity for automatic top-ups. 3. Active payment addresses in the required networks. *** ### Gas Manager Network Parameters | Chain | Native Coin | Top-Up Threshold, USD | Top-Up Amount, USD | Gas Manager Fee, % | | --------- | ----------- | --------------------: | -----------------: | -----------------: | | Bitcoin | BTC | 30.00 | 60.00 | 10.00 | | BNB chain | BNB | 10.00 | 30.00 | 10.00 | | Ethereum | ETH | 10.00 | 30.00 | 10.00 | | Fraxtal | ETH | 10.00 | 20.00 | 10.00 | | Litecoin | LTC | 10.00 | 20.00 | 10.00 | | Polygon | MATIC | 10.00 | 20.00 | 10.00 | | Solana | SOL | 10.00 | 20.00 | 10.00 | | Ton | TON | 10.00 | 20.00 | 10.00 | | Tron | TRX | 20.00 | 50.00 | 10.00 | # Private Withdrawals Move funds privately—without revealing a link between your merchant treasury and the destination address. **Private Withdrawals** route your payout through the Hinkal zero-knowledge protocol while keeping your day-to-day workflow inside the OMY dashboard. #### How it works 1. **Enablement & network setup**\ OmyPayments enables Private Withdrawals for your workspace and for specific networks. Per-network parameters (including a native-coin gas setting) are configured on our side. 2. **Address allowlisting (Hinkal)**\ Your payout (destination) addresses must be allowlisted by Hinkal. As part of this, an **access NFT** is minted to the approved addresses—OmyPayments coordinates this with the Hinkal team. 3. **Create a withdrawal, then toggle “Is Private”**\ In the dashboard, start a withdrawal as usual and tick **Is Private**. We handle the rest: approve (for tokens), deposit into Hinkal, and execute the private withdrawal via relayer. 4. **Track status & receipt**\ You’ll see the result and on-chain hash in your standard withdrawals table; the low-level private-flow states are tracked internally by OmyPayments. Automated retries are built in, with safe failures if a step cannot be mined. #### Key features * **ZK privacy via Hinkal** — shields the link between source and destination. * **Familiar UX** — same withdrawal flow, plus a single **Is Private** checkbox. * **Token and native support** — handles approvals for tokens; deposits natively when applicable. * **Operational safeguards** — staged processing with idempotent retries and clear terminal states (**success/failed**). * **Unified reporting** — merchants see outcomes in the main `payment_withdrawals` view with the final tx hash. #### Benefits for merchants * **Treasury privacy** for sensitive payouts (vendor settlements, grants, internal rebalancing). * **Minimal lift** — OmyPayments handles allowlisting, access NFT minting, and protocol nuances. * **Predictable operations** — robust retry logic and explicit statuses; support can step in for rare SDK issues. #### Getting started 1. **Request activation** of Private Withdrawals for your workspace and target networks. 2. **Submit destination addresses** for Hinkal allowlisting (we’ll coordinate and mint the required access NFTs). 3. In the dashboard, create a withdrawal, enable **Is Private**, and **run a small test**. 4. **Monitor the result** in your standard withdrawals page; contact support if a run pauses for review. *Start in your dashboard:* [*https://dashboard.omypayments.com/*](https://dashboard.omypayments.com/) # Sweeper (Balance Cleaner) Keep hot wallets lean and safe by automatically sweeping coins and tokens to your cold treasury. This page explains how the sweeper is started, how it decides what to move, and which parameters control its behavior. *** ### What the sweeper does * Iterates over **all active hot addresses** in the payment system, checks balances, and tries to move funds to **cold addresses**. * **Coins (native assets):** sent via a normal transfer; gas is paid by the sending address. * **Tokens (e.g., ERC-20/TRC-20):** require native coins on the source address to pay gas, so the sweeper first tops up a small amount of native coin to that address, then sends the tokens to cold storage. # White Label Payment service providers, fintech apps, neo banks and other projects are welcome to build your unique crypto payment solution on top of OMY Payments infrastructure. We consider different types of white label provision (dedicated API, tailor made features, sharing infrastructure and others). Please contact our BD to learn more. # Affiliate program #### Partner with Us & Monetize Your Network Our Affiliate Program offers an excellent opportunity for individuals, businesses, and influencers to generate passive income by referring merchants to our platform. With a competitive commission structure, you can earn up to 50% of our transaction fees for each referred merchant. #### How It Works 1. **Sign Up & Get Your Referral Link** – Join our affiliate program and receive a unique tracking link. 2. **Promote Our Services** – Share your link via websites, blogs, social media, or direct outreach to potential merchants. 3. **Earn Commissions** – Every merchant that signs up through your referral link (or direct recomendation to our sales dep.) generates ongoing earnings for you based on transaction fees. #### Why Join Our Affiliate Program? * **High Commission Rates** – Earn up to 50% of our transaction fees. * **Recurring Earnings** – Get rewarded every time your referred merchants process payments. * **No Limits** – The more merchants you onboard, the higher your potential earnings. * **Real-Time Tracking** – Monitor clicks, sign-ups, and commissions via an intuitive dashboard. * **Marketing Support** – Access banners, content, and promotional materials to maximize conversions. #### Who Can Benefit? Our affiliate program is ideal for: * A well-connected person in the field of high-risk and e-commerce. * Digital marketing professionals and agencies. * Bloggers and content creators in the finance and crypto space. * SaaS providers looking to offer additional services. * Entrepreneurs and influencers with strong business networks. #### Getting Started 1. **Register as an Affiliate** – Quick and free sign-up process. 2. **Start Promoting** – Share your referral link and use provided marketing assets. 3. **Earn & Grow** – Receive commissions as your referrals generate revenue. #### Maximize Your Earnings Affiliates can scale their earnings by engaging in targeted campaigns, leveraging social media influence, or partnering with high-volume businesses and also participating in special events with OMY promo materials.\ There’s no cap on how much you can earn, making this a lucrative opportunity. Join our Affiliate Program today and start earning from every successful referral! # Demo Shop Explore how our payment processing works in real-time with our **Demo Shop**. This showcase allows you to experience the speed and convenience of **OMY Payments** firsthand. Make test transactions, navigate through the checkout process, and see how seamless and efficient payments can be. [Try it now!](https://testshop.omypayments.com/) # Basics Cryptocurrency payments are reshaping how businesses and individuals handle transactions worldwide. At OMY Payments, we make crypto transactions seamless, fast, and secure. Here’s a basic guide to understanding how invoices work, accepting crypto payments, and withdrawing your funds in both cryptocurrency and fiat currency. {% content-ref url="/pages/hSr4QtLashqTOcWFFjHh" %} [What is an Invoice?](/getting-started/editor/what-is-an-invoice) {% endcontent-ref %} {% content-ref url="/pages/Jckq6HJ5RakqZTyjzPvY" %} [Accepting Payments](/getting-started/editor/accepting-payments) {% endcontent-ref %} {% content-ref url="/pages/bOwQB0y4pHHXJQHw7Qxm" %} [Withdrawing Your Funds from OMY Payments](/getting-started/editor/withdrawing-your-funds-from-omy-payments) {% endcontent-ref %} {% content-ref url="/pages/1WDOZGI6OltFSLu36d2b" %} [Security and Transparency](/getting-started/editor/security-and-transparency) {% endcontent-ref %} # What is an Invoice? In cryptocurrency payments, an invoice functions similarly to a traditional invoice—it specifies how much the customer needs to pay and provides essential transaction information. However, unlike traditional invoices, crypto invoices include additional information necessary to execute blockchain transactions: * **Crypto Amount and Currency:** The invoice clearly specifies the amount and type of cryptocurrency to send (e.g., Bitcoin, Ethereum, USDT, etc.). * **Wallet Address:** Each invoice provides a unique wallet address for payment receipt. This ensures security, accuracy, and simplifies tracking. * **QR Code:** To ease the payment process, invoices often include QR codes. Customers scan these codes with their crypto wallets to quickly and accurately initiate payments. OMY Payments generates crypto invoices automatically, ensuring ease of use and accuracy in your payment management processes. # Accepting Payments Accepting crypto payments through OMY Payments is intuitive and secure. Here’s a quick breakdown of the process: 1. **Invoice Generation:** When a customer initiates a purchase or payment, OMY Payments automatically creates a unique crypto invoice with a wallet address or QR code. 2. **Payment Initiation:** The customer then sends the specified cryptocurrency amount directly to the provided wallet address by scanning the QR code or manually entering the wallet details in their crypto wallet app. 3. **Transaction Verification:** Once sent, the blockchain network validates the transaction. Depending on the cryptocurrency network traffic, verification generally occurs within a few seconds to minutes. 4. **Payment Confirmation:** As soon as the blockchain confirms the transaction, OMY Payments updates your dashboard with real-time status updates, marking the invoice as paid. This streamlined workflow makes cryptocurrency acceptance as straightforward as traditional payment methods. # Withdrawing Your Funds from OMY Payments After you’ve successfully received crypto payments, OMY Payments offers easy ways to access and withdraw your funds. You can withdraw your funds either in crypto or fiat currencies. #### Withdrawals in Crypto: * Easily transfer received funds directly to your external crypto wallets. * Select your desired cryptocurrency and input your wallet address. * Once initiated, the blockchain processes your withdrawal swiftly, securely transferring your crypto to your personal wallet. #### Withdrawals in Fiat Currency: * Convert your cryptocurrency directly to fiat currency through OMY Payments’ built-in exchange functionality. * Fiat withdrawals typically process within standard banking timeframes (usually 1-3 business days, depending on your bank and location). # Security and Transparency OMY Payments prioritizes safety and transparency in every transaction. Each crypto transaction is recorded on the blockchain, a decentralized public ledger, ensuring immutable records and reducing risks associated with traditional payments. Furthermore, we implement robust security measures, including encryption and two-factor authentication, safeguarding your assets at every stage of the payment process. With OMY Payments, managing cryptocurrency payments, invoicing, and fund withdrawals has never been easier or more secure. Whether you're new to cryptocurrency or experienced in digital assets, our platform simplifies transactions, allowing you to focus on growing your business confidently and efficiently. # Implementation Before you can flip the switch, create an account in the OMY Payments dashboard () and complete any required verification—this is mandatory only if you expect higher-than-starter limits from day one. Once your account is set up, you can go live in minutes with our no-code widgets, or dive into the [API](/api/api-endpoints) to design a fully custom payment path that matches your product’s UX. See more here: {% content-ref url="/pages/gdIDy48iWi7LY9DeFNfs" %} [Balance Notifications](/getting-started/markdown/balance-notifications) {% endcontent-ref %} {% content-ref url="/pages/r3JfZmGJoPhkWSXmnwvL" %} [Enabling Tokens](/getting-started/markdown/enabling-tokens) {% endcontent-ref %} # Balance Notifications Keep your **address-flow** wallets topped up and avoid payment failures by letting our Telegram bot watch your native-currency balances for you. Merchants that use **address flow** (a dedicated pool of deposit addresses) must always hold enough native currency (e.g., ETH, BTC, MATIC) to cover miner fees and on-chain actions. Our **Omy Payments Liquidity Bot** sends an alert as soon as any address-pool balance drops below the minimum we enforce, so you can refill in time. #### 1. Prerequisites | Requirement | Details | | ------------------------ | ------------------------------------------------------------------------------------------------------------- | | **Address-flow enabled** | Address flow is provisioned manually. Contact **OMY Payments support** to have it activated for your account. | | **Telegram account** | You’ll set up a private group in Telegram. | | **Dashboard access** | Permissions to edit **Account → Notifications** in the OMY dashboard. | #### 2. One-time setup (≈ 3 min) 1. **Create a private group** in Telegram (⋯ → *New Group*). 2. **Invite the bot**: `@omypayments_liquid_bot` (display name *OmyPaymentsLiquidityBot*). 3. **Find the group ID** * Send `/start` to the group. * Add the `@getmyid_bot` to the group. * Copy the numeric `-100xxxxxxxxxx` ID. 4. **Save the ID in your dashboard** * Go to **Account → Notifications → Balance alerts**. * Paste the group ID and click **Save**. That’s it—no extra API keys or webhooks required. **Notification example:** `ALERT!` \ `Payment address (hot) balance is 0.000077655418896013 BNB (0.05 USD)`\ `Minimum recommendation balance: 0.029338571071720820 BNB (20 USD)`\ `Address: 0x0000` # Enabling Tokens Activate only the assets you really need and fine-tune their payout settings in a single place. *** #### 1. Open the **Assets** page In the left-hand menu of the OMY dashboard you’ll find **Assets**.\ The table lists every cryptocurrency and stable-coin currently supported by OMY. #### 2. Edit the desired token Click the **✏️ (pencil)** icon in the row of the asset you want to enable.\ A modal titled **Update payment asset** appears. #### 3. Configure the asset | Field | What it does | Typical value | | --------------- | ------------------------------------------------------------------- | ------------------------------------- | | **Is Active** | Toggles the token on/off for your integration. | ✅ *(checked)* to accept this asset | | **Wallet** | Withdrawal address where collected funds will be swept. | Your exchange or cold-storage address | | **Fee percent** | Variable fee OMY deducts from each payment. | `0.5` → means 0.5 % | | **Fee USD** | Fixed fee in USD (converted on the fly to the settlement currency). | `0.30` | Click **Update** to confirm. #### # Use OMY with no code GitBook allows you to add images and media easily to your docs. Simply drag a file into the editor, or use the file manager in the upper right corner to upload multiple images at once.

Add alt text and captions to your images

{% hint style="info" %} You can also add images simply by copying and pasting them directly into the editor — and GitBook will automatically add it to your file manager. {% endhint %} # Create Payment Links # Create a buy button # Send invoices # Send quotes # Plugins for CMS Тут разместим перечень готовых плагинов для CMS со ссылками на их реализацию на Github или ещё куда-то, хз куда их публикуют, надо посмотреть у конкурентов как реализовано. # Overview Omypayments API is a powerful cryptocurrency payment solution designed for merchants who want to accept digital assets securely and efficiently. It allows businesses to integrate seamless crypto transactions, ensuring speed, reliability, and ease of use. With Omypayments API, merchants can: * Accept payments in multiple cryptocurrencies across various blockchain networks. * Generate invoices dynamically, enabling customers to select their preferred payment asset. * Monitor transaction statuses in real time via callbacks. * Easily integrate the system with their platforms using straightforward RESTful API calls. #### Key Features * **Multi-Chain Support**: Works with EVM-based networks (Ethereum, BSC, Polygon), as well as TON, TRON and Solana. * **Secure Transactions**: Encrypted API communication and authentication via API keys. * **Flexible Invoicing**: Merchants can create invoices in fiat equivalents, and users can pay in crypto. * **Real-Time Callbacks**: Automated status updates for payment tracking. * **User-Friendly API**: Clear documentation, easy integration, and predictable responses. # Authentication To use the API, merchants must obtain an API key from their personal account. You can retrieve your API key by logging in at: [https://dashboard.omypayments.com/](https://dashboard.omypayments.com/site/login). Without a valid API key, all requests will be rejected. Include the API key in the header of each request as follows: ```bash curl -X GET -H "apiKey: yourApiKey" https://api.omypayments.com/ ``` If the API key is missing, the server will respond with: ```json { "success": false, "message": "Missing api key", "statusCode": 0 } ``` # API Reference ## The `fee` object One shape, identical on every entity. All four keys are **always present**; when something does not apply or was never recorded, the value is `null` - never `0`, never an empty array. ```json { "network": [ /* FeeLeg[] or null */ ], "service": { /* FeeLeg or null */ }, "exchange": { /* FeeLeg or null */ }, "totalInUsd": "1.84" } ``` | Key | Meaning | | ------------ | ------------------------------------------------------------------------------------------------- | | `network` | Blockchain gas, as an **array of legs** - one per currency. `null` when there are none | | `service` | The OmyPayments platform fee | | `exchange` | Fee charged by the exchange. Only ever filled for swaps; other entities carry the key with `null` | | `totalInUsd` | Sum, in USD, of **only** the legs with `isChargedToMerchant: true` | ### A fee leg ```json { "amount": "210000000000000", "amountFormatted": "0.00021", "currency": "ETH", "cryptoId": "eth-ethereum", "networkId": "ETH", "amountInUsd": "0.84", "isChargedToMerchant": true } ``` | Field | Type | Meaning | | --------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | `amount` | `string` | 🔴 **Minimal units** (wei / satoshi / …), same convention as every other amount in this API. Never a decimal | | `amountFormatted` | `string` | The same value as a decimal string, already divided by the currency's `decimals` | | `currency` | `string` | Ticker of the currency the fee was actually taken in | | `cryptoId` | `string \| null` | Our crypto identifier. `null` when the amount is in a network's native coin that we do not track as a separate crypto record | | `networkId` | `string \| null` | Our network identifier | | `amountInUsd` | `string \| null` | The USD value **recorded when the operation happened**. `null` when it was never recorded - see below. This is never a fresh conversion at read time | | `isChargedToMerchant` | `bool` | Whether you were actually billed for this leg | #### `isChargedToMerchant: false` Some legs are shown for transparency but are **not** billed to you, and they are **excluded from `totalInUsd`**. That happens when the gas is funded from somewhere other than your balance: * mass-payout gas - spent from your own payment address, which the Gas Manager tops up; * swap gas on the source side for address-flow merchants - self-funded from your own addresses; * swap bridge-deposit gas - not billed to anyone; * the `topUp` leg of a Gas Manager operation - the native coin we credit to your address. If you are computing "what did this operation cost me", sum only legs with `isChargedToMerchant: true` - or simply read `totalInUsd`, which already does exactly that. ### 🔴 When is `network` `null`, and why `network: null` never means "we hid something". It means there is no network leg to report. | Entity | `network` is `null` … | Why | | ------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Invoice** | **always** | The gas of the incoming payment is paid by the payer. An invoice has no network fee of ours to report | | **Deposit** | **always** | Same: an incoming operation, its gas is the sender's | | **Withdrawal** | before the transaction is sent; and **always** for address-flow merchants | Before sending, the gas is not yet known. For address-flow merchants the withdrawal leaves your own address and its gas is funded by the Gas Manager - look it up in `gas-manager/list`, not here | | **Mass payout task** | until the task has been sent | The gas is unknown before sending | | **Swap** | until at least one gas phase has completed | Legs appear as the swap progresses through its phases | | **Gas Manager operation** | **always** | The gas of the distributing transaction burns on *our* sender address and is not billed to you | ### When is `totalInUsd` `null` `totalInUsd` is `null` when at least one **charged** leg has an unknown `amountInUsd`. A partial total would look like a smaller charge than the real one, so we report nothing rather than a misleading number. In practice: * **Deposits created before this release** - the USD value of the deposit fee was not persisted back then and is never backfilled, so `service.amountInUsd` and `totalInUsd` are both `null`. The fee itself (`service.amount`) is present and correct. * **Mass payout tasks** - the gas leg has `amountInUsd: null`, but it is *not charged*, so it does not void the total. `totalInUsd` there equals the service fee and is not `null`. * **Unfinished swaps** - `totalInUsd` mirrors the stored total, which is only written when the swap finishes; the legs known so far are still returned. ### Deprecated: `gas` on withdrawals The withdrawal response still contains its original `gas` object: ```json "gas": {"amount": "210000", "amountInUsd": "0.84", "crypto": {…}, "network": {…}} ``` It is **deprecated** in favour of `fee.network[]` but keeps being returned - nothing is being removed from the withdrawal contract in this release. Both are built from the same stored columns and always agree; new integrations should read `fee.network[]`. ### Units, one more time `amount` is in **minimal units**. A 1.2 USDT fee on a 6-decimals token is `"1200000"`, and on an 18-decimals token it is `"1200000000000000000"`. Use `amountFormatted` if you want the decimal value without doing the division yourself, and `crypto.decimals` on the same response if you want to do it yourself. ### A note on USD precision `amountInUsd` is returned exactly as it was stored at the time of the operation. Different entities were historically stored at different precision, so you may see `"1.6000"` on a swap leg and `"0.84"` on a withdrawal leg in the same integration. Both are exact; neither is rounded on read. Compare them as decimals, not as strings. # API Endpoints {% content-ref url="/pages/xAzVVXqLQB2iynNck64e" %} [Broken mention](broken://pages/xAzVVXqLQB2iynNck64e) {% endcontent-ref %} {% content-ref url="/pages/eZiG4JYUAib1h6IOuD3M" %} [Get Merchant Assets](/api/api-endpoints/assets/get-merchant-assets) {% endcontent-ref %} {% content-ref url="/pages/khdqCorxXsxPb5dn53Z8" %} [Create Invoice](/api/api-endpoints/invoices/create-invoice) {% endcontent-ref %} {% content-ref url="/pages/riCfyKrvH1hQPET7q9eP" %} [Create Invoice by Crypto](/api/api-endpoints/invoices/create-invoice-by-crypto) {% endcontent-ref %} {% content-ref url="/pages/PGcHJ01vkdDYJcGAH981" %} [Get Invoice Data](/api/api-endpoints/invoices/get-invoice-data) {% endcontent-ref %} {% content-ref url="/pages/1tcXkEBORurpRafvp1LL" %} [Broken mention](broken://pages/1tcXkEBORurpRafvp1LL) {% endcontent-ref %} # Assets An **asset** is one currency on one network enabled on your merchant account - say USDT on Tron, or ETH on Ethereum. Assets are what invoices are paid into, what balances are held in, and what withdrawals are sent from. Everything else in this API refers to them by `assetId`. This page documents the HTTP endpoints you'll call from your backend. Authentication and the error-envelope format follow the public API style. > **Base URL**: `https://api.omypayments.com`\ > **Version**: `v1` (all endpoints below start with `/1.0/...`)\ > **Auth**: add your API key in the header: `apiKey: `\ > **Permission**: the API key must have the **invoice** permission enabled, otherwise requests are rejected with `403 Forbidden`. **What you get from an asset** * `assetId` - the identifier every other endpoint expects: creating invoices, requesting withdrawals, filtering transactions. * `crypto.decimals` - how many decimals the token has. You need it for every amount you send us or read from us, because all amounts travel as integer strings in minimal units. * Balances - what is available to spend, what is still awaiting confirmations, and what is held. * The default withdrawal wallet, if one is set for the asset. **Prerequisites** * Assets are enabled in the merchant dashboard, not through the API. This section is read-only. * Only **active** assets are returned. An asset switched off in the dashboard disappears from these responses, and invoices can no longer be created for it. **Typical flow** 1. `assets` once at integration time - cache the `assetId` and `decimals` values you need. 2. `asset` whenever you need a fresh balance for one asset. Balances change as payments arrive and withdrawals leave, so don't cache them. Identifiers and decimals are stable and safe to cache. **A word on amounts** Every amount in this API - invoice totals, withdrawal amounts, balances, fees - is an integer string in the token's minimal units, never a decimal number. For a token with 6 decimals, `"100000000"` means 100 tokens. Divide by `10^decimals` for display, and never parse these values as floats: at 18 decimals a float silently loses precision. *** # Get Merchant Assets **Prerequisites:** Make sure the tokens you intend to accept are **enabled and fully configured** in the **Assets** section of your OMY Payments dashboard (). {% content-ref url="/pages/r3JfZmGJoPhkWSXmnwvL" %} [Enabling Tokens](/getting-started/markdown/enabling-tokens) {% endcontent-ref %} **Request:** ```http GET /1.0/merchant/assets ``` **Response (200 OK):** ```json { "assets": [ // Merchant assets list { "id": "uuid", // Asset UUID "wallet": "0x0000000000000000000000000000000000000000", // Merchant asset wallet address "feePercent": "5", // Metchant asset fee in percent "feeUsd": "1", // Merchant asset fee in USD "balance": "0", // Merchant asset balance "balanceInUsd": "0", // Merchant asset balance in USD "crypto": { // Asset cryto "id": "uuid", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT" // Crypto symbol "contractAddress": "0x0000000000000000000000000000000000000000" // Crypto contract address "decimals": 6 // Crypto decimals "logoURI": "https://..." // Crypto logo URI }, "network": { // Asset network "id": "UUID", // Network UUID "title": "Ethereum", // Network title "symbol": "ETH", // Network symbol "chainId": "1" // Network chain ID "chainType": "evm" // Network type }, "createdAt": "2025-01-01 00:00:00" // Asset datetime creation (UTC+0) } ] } ``` **Error Response (500 Internal Server Error):** ```json { "success": false, "message": "Internal Server Error", "statusCode": 500 } ``` # Get Merchant Asset Data **Prerequisites:** Make sure the tokens you intend to accept are **enabled and fully configured** in the **Assets** section of your OMY Payments dashboard (). {% content-ref url="/pages/r3JfZmGJoPhkWSXmnwvL" %} [Enabling Tokens](/getting-started/markdown/enabling-tokens) {% endcontent-ref %} **Request:** ```http GET /1.0/merchant/asset?id=UUID ``` **Response (200 OK):** ```json { "id": "uuid", // Asset UUID "wallet": "0x0000000000000000000000000000000000000000", // Merchant asset wallet address "feePercent": "5", // Metchant asset fee in percent "feeUsd": "1", // Merchant asset fee in USD "balance": "0", // Merchant asset balance "balanceInUsd": "0", // Merchant asset balance in USD "balanceForWithdrawal": "0", // Merchant asset balance that available for withdrawal "crypto": { // Asset cryto "id": "uuid", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT" // Crypto symbol "contractAddress": "0x0000000000000000000000000000000000000000" // Crypto contract address "decimals": 6 // Crypto decimals "logoURI": "https://..." // Crypto logo URI }, "network": { // Asset network "id": "UUID", // Network UUID "title": "Ethereum", // Network title "symbol": "ETH", // Network symbol "chainId": "1" // Network chain ID "chainType": "evm" // Network type }, "createdAt": "2025-01-01 00:00:00" // Asset datetime creation (UTC+0) } ``` **Error Response (500 Internal Server Error):** ```json { "success": false, "message": "Internal Server Error", "statusCode": 500 } ``` # Invoices Charge your customers in crypto. You create an invoice for an amount, we give you a payment page and an address to pay to, and you learn about the payment through polling or callbacks. This page documents the HTTP endpoints you'll call from your backend. Authentication and the error-envelope format follow the public API style. > **Base URL**: `https://api.omypayments.com`\ > **Version**: `v2` for creating invoices, `v1` for reading them (paths below say which)\ > **Auth**: add your API key in the header: `apiKey: `\ > **Permission**: the API key must have the **invoice** permission enabled, otherwise requests are rejected with `403 Forbidden`. **Two ways to price an invoice** * `create-invoice` - you name the amount **in USD cents**, we convert it to crypto at the current rate when the customer picks an asset. Use this when your prices are in fiat. * `create-invoice-by-crypto` - you name the amount **in the token's minimal units**, and that exact amount is what the customer pays. Use this when you're billing in crypto. **Prerequisites** * Amounts are never floating-point. USD is passed in **cents** (`"1050"` = $10.50); crypto is passed in the token's **minimal units** (an integer string, no decimal point - for a token with 6 decimals, 100 tokens = `"100000000"`). Use `crypto.decimals` from the Assets section to convert. * At least one asset must be active on your account before you can be paid — see Assets. * The customer may choose the asset on the payment page, or you may fix it at creation time. An invoice created without an asset stays payable until someone picks one. **Typical flow** 1. `create-invoice` or `create-invoice-by-crypto` → you get an invoice id and a payment page link. 2. Send the customer to the payment page. 3. Track the result with `invoice-info`, the invoices list, or callbacks. Callbacks are the recommended way - no polling. **Invoice statuses** | Status | Meaning | | ---------- | ------------------------------------------------------------------------- | | `new` | Invoice created, nothing received yet. | | `pending` | A payment was detected and is awaiting confirmations. | | `finished` | Paid in full and credited to your asset balance. | | `rejected` | Expired or declined without being paid. | | `frozen` | Held for a compliance check; funds are not credited until it is resolved. | | `refunded` | The received amount was sent back to the payer. | The full lifecycle, including partial and late payments, is described in Invoice Statuses. **Fees** Every invoice response carries a `fee` object describing what we charged you. Invoices have no network fee — the payer covers the on-chain cost of sending, so `fee.network` is always `null` for this entity. *** # Create Invoice **Request:** ```http POST /2.0/merchant/create-invoice ``` **Request Body:** ```json { "usdAmountInCents": 10000, // Invoice amount in cents "assetId": "uuid", // Optional: Predefined asset ID for payment "productTitle": "Test Product", // Optional: Product title "extraData": "Optional data", // Optional: Additional invoice parameters "paymentDelayTime": 86400 // Optional: Payment delay time in seconds (max 24 hours or 86400 seconds) } ``` **Response (200 OK):** ```json { "id": "UUID", // Invoice ID "usdAmount": "0", // Invoice amount in USD "status": "pending", // Invoice status "paymentPageLink": "https://pp.omypayments.com/?id=UUID", // Link to the payment page "productTitle": "Test Product", // Product title "extraData": null, // Additional invoice information. "cryptoAmount": "0", // Amount in selected cryptocurrency (or null if not chosen) "crypto": { // Cryptocurrency data (or null if not chosen) "id": "uuid", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT" // Crypto symbol "contractAddress": "0x0000000000000000000000000000000000000000" // Crypto contract address "decimals": 6 // Crypto decimals "logoURI": "https://..." // Crypto logo URI }, "network": { // Network data (or null if not chosen) "id": "UUID", // Network UUID "chainId": "56", // Network chain ID "symbol": "BSC", // Network symbol "name": "BNB Chain", // Network title "networkType": "evm" // Network type }, "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "address": "0x0000000000000000000000000000000000000000", // Payment address (or null if not chosen) "expiredAt": "2025-03-11 14:30:16" // Invoice expiration datetime (UTC+0) } ``` **Error Responses:** * **400 Bad Request (Validation Error):** ```json { "success": false, "message": "Validation error", "errors": [ { "field": "usdAmountInCents", "messages": ["Invalid value format"] } ] } ``` * **500 Internal Server Error:** ```json { "success": false, "message": "Internal Server Error", "statusCode": 500 } ``` # Create Invoice by Crypto **Request:** ```http POST /2.0/merchant/create-invoice-by-crypto ``` **Request Body:** ```json { "cryptoAmount": "100020722776701016039", // Required: Cryptocurrency amount in wei (uint) "assetId": "uuid", // Required: Predefined asset ID for payment "productTitle": "Test Product", // Optional: Product title "extraData": "Optional data", // Optional: Additional invoice parameters "paymentDelayTime": 86400 // Optional: Payment delay time in seconds (max 24 hours or 86400 seconds) } ``` **Response (200 OK):** ```json { "id": "UUID", // Invoice ID "usdAmount": "100.00", // Invoice amount in USD "status": "pending", // Invoice status "paymentPageLink": "https://pp.omypayments.com/?id=UUID", // Link to the payment page "productTitle": "Test Product", // Product title "extraData": null, // Additional invoice information "cryptoAmount": "0", // Amount in cryptocurrency "crypto": { // Crypto data "id": "uuid", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT" // Crypto symbol "contractAddress": "0x0000000000000000000000000000000000000000" // Crypto contract address "decimals": 6 // Crypto decimals "logoURI": "https://..." // Crypto logo URI }, "network": { // Network data "id": "UUID", // Network UUID "chainId": "56", // Network chain ID "symbol": "BSC", // Network symbol "name": "BNB Chain", // Network title "networkType": "evm" // Network type }, "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "address": "0x0000000000000000000000000000000000000000", // Payment address "expiredAt": "2025-01-01 00:00:00" // Invoice expiration datetime (UTC+0) } ``` **Error Responses:** * **400 Bad Request (Validation Error):** ```json { "success": false, "message": "Validation error", "errors": [ { "field": "cryptoAmount", "messages": ["Invalid value format"] } ] } ``` * **500 Internal Server Error:** ```json { "success": false, "message": "Internal Server Error", "statusCode": 500 } ``` # Get Invoice Data **Request:** ```http GET /1.0/merchant/invoice-info?id=UUID ``` **Response (200 OK):** ```json { "id": "UUID", // Invoice ID "usdAmount": "100.00", // Invoice amount in USD "status": "pending", // Invoice status "paymentPageLink": "https://pp.omypayments.com/?id=UUID", // Payment page link "productTitle": "Test Product", // Product title "extraData": null, // Additional invoice information "cryptoAmount": "0", // Amount in selected cryptocurrency (or null if not chosen) "crypto": { // Cryptocurrency data (or null if not chosen) "id": "uuid", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT" // Crypto symbol "contractAddress": "0x0000000000000000000000000000000000000000", // Crypto contract address "decimals": 6, // Crypto decimals "logoURI": "https://..." // Crypto logo URI }, "network": { // Network data (or null if not chosen) "id": "UUID", // Network UUID "chainId": "56", // Network chain ID "symbol": "BSC", // Network symbol "name": "BNB Chain", // Network title "networkType": "evm" // Network type }, "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "address": "0x0000000000000000000000000000000000000000", // Payment address (or null if not chosen) "expiredAt": "2025-01-01 00:00:00" // Invoice expiration datetime (UTC+0) } ``` **Error Responses:** * **400 Bad Request (Validation Error):** ```json { "success": false, "message": "Validation error", "errors": [ { "field": "id", "messages": ["Invoice not found"] } ] } ``` * **500 Internal Server Error:** ```json { "success": false, "message": "Internal Server Error", "statusCode": 500 } ``` # Deposits A **deposit** is money that arrived at one of your addresses without an invoice behind it. Someone sent funds directly to an address of yours, we detected the transfer on-chain, took our fee and credited the rest to the asset balance. This section lets you read those deposits from your backend. > **Base URL**: `https://api.omypayments.com`\ > **Version**: `v2` (all endpoints below start with `/2.0/...`)\ > **Auth**: add your API key in the header: `apiKey: `\ > **Permission**: the API key must have the **invoice** permission enabled — deposits are the incoming-payment side of the same permission, and there is no separate deposit flag. Without it requests are rejected with `403 Forbidden`. **Deposit or invoice?** Both put money on your balance, and both charge you a platform fee. The difference is who initiated the accounting: * An **invoice** is something you created up front: an expected amount, a payment page, a status you can follow from `new` to `finished`. * A **deposit** is discovered after the fact. Nobody announced it - a transfer simply landed on your address, and we recorded it. There is nothing to create and nothing to cancel. If you only ever charge customers through invoices, you may still see deposits: a customer paying an old address again, or a top-up you sent yourself, both arrive as deposits. **Prerequisites** * Deposits are created by us, not by you. There is no endpoint to create one. * Amounts follow the usual rule: integer strings in the token's minimal units. See Assets for `decimals`. * The deposit id is not something you can guess ahead of time. You learn it either from the ledger - deposits appear in the transaction list under the `deposit` opcode - or from a callback. **Deposit statuses** | Status | Meaning | | ---------- | ---------------------------------------------------------------------------------------------- | | `success` | Credited to your asset balance, minus our fee. | | `frozen` | Held for a compliance check. The funds are not on your available balance until it is resolved. | | `refunded` | The received amount was sent back to the sender. | There is no `pending` state here: a deposit is only recorded once the incoming transfer has been confirmed on-chain. **Fees** Every deposit carries a `fee` object with what we charged. Deposits have **no network fee** — the sender paid the on-chain cost of the transfer, so `fee.network` is always `null` for this entity. Only `fee.service` is populated. For deposits recorded before the USD figure started being stored, `fee.service.amountInUsd` is `null` while the crypto amount is present. That is missing history, not a zero fee. *** # Get a deposit `GET /2.0/deposit/get?id={uuid}` One deposit of yours, by id. **Permission:** `can_invoice` - deposits are the incoming-payment side of the same permission, and there is no separate deposit flag. | Query parameter | Required | Type | | --------------- | -------- | ---- | | `id` | yes | UUID | #### Response `200` ```json { "id": "{uuid}", "status": "success", "amount": "50000000000000000000", "assetId": "{assetId}", "crypto": { "id": "{cryptoId}", "title": "Binance Pegged USDT", "symbol": "USDT", "contractAddress": "0x0000000000000000000000000000000000000000", "decimals": 18, "logoURI": "https://raw.githubusercontent.com/0xsquid/assets/main/images/tokens/usdt.svg" }, "network": { "id": "{networkId}", "title": "BNB Chain", "symbol": "BSC", "chainId": "56", "networkType": "evm" }, "txHash": "{txHash}", "txFrom": "0x0000000000000000000000000000000000000000", "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "createdAt": "2026-07-28T10:42:08+00:00" } ``` `status` is one of `success`, `frozen`, `refunded` - a deposit is never in an intermediate state by the time you can read it. For a deposit created **before this release**, `service.amountInUsd` and `totalInUsd` are `null` (the USD value was not recorded back then and is never backfilled). `service.amount` is present. #### Codes | Code | When | | ----- | --------------------------------------------------------------------------------------------------- | | `200` | OK | | `400` | `id` is not a valid UUID, or missing | | `401` | Missing or invalid `apiKey` | | `403` | The apiKey has no `can_invoice` permission | | `404` | No such deposit - **or it belongs to another merchant**. The two are deliberately indistinguishable | | `429` | Rate limit (50 rps) | # Swaps Estimate and execute swaps between two of your merchant assets (a different token and/or network). This page documents the HTTP endpoints you’ll call from your backend. Authentication and the error-envelope format follow the public API style. > **Base URL**: `https://api.omypayments.com`\ > **Version**: `v2` (all endpoints below start with `/2.0/...`)\ > **Auth**: add your API key in the header: `apiKey: `\ > **Permission**: the API key must have the **swap** permission enabled, otherwise requests are rejected with `403 Forbidden`. **Prerequisites** * Both the source and target assets must be enabled in **Assets** (dashboard). * `amount` is expressed in the token’s base units (integer string, no decimal point). For USDT with 6 decimals, `100` USDT = `"100000000"` — see `crypto.decimals` on the “Get Merchant Asset Data” endpoint to convert. * An estimate is held for **30 minutes** and is single-use: creating a swap consumes it. * Native coins (e.g. ETH, BNB) cannot be used as the **target** asset. * Rate limit: **50 requests/second**. **Typical flow** 1. `swap/estimate` → 2. `swap/create` (reserves funds, starts processing) → 3. `swap/get` and/or callbacks to track status. **Swap statuses** | Status | Meaning | | ------------- | ------------------------------------------------------------------ | | `new` | Swap created, funds reserved, awaiting processing. | | `in_progress` | Swap is being executed on-chain / via the routing provider. | | `finished` | Swap completed; `amountTo`, `hashFrom`, `hashTo` are populated. | | `rejected` | Swap failed; reserved funds are returned to the available balance. | *** # Estimate a swap Get a quote for swapping one merchant asset into another. The estimate is held for \*\*30 minutes\*\* and is single-use — creating a swap from it consumes the quote. **Endpoint**\ `POST /2.0/swap/estimate` **Body parameters** | Parameter | Type | Required | Description | | ------------- | ------ | -------- | ------------------------------------------------------------------------------------------------------- | | `assetIdFrom` | string | yes | UUID of the source merchant asset (the asset you swap from). | | `assetIdTo` | string | yes | UUID of the target merchant asset (the asset you receive). | | `amount` | string | yes | Source amount in the asset’s base units (integer string, no decimal point). `100` USDT = `"100000000"`. | **cURL** ```bash curl -X POST "/2.0/swap/estimate" \ -H "Content-Type: application/json" \ -H "apiKey: " \ -d '{"assetIdFrom":"{assetIdFrom}","assetIdTo":"{assetIdTo}","amount":"{amount}"}' ``` **Response (200 OK)** ```json { "id": "estimage-uuid", // Estimate ID — pass this to "Create a swap" "serviceId": "1inch", // Internal routing service identifier "routeType": "dex", // Route type: "dex" or "cex" "estimatedAmount": "99500000" // Estimated amount you will receive (target base units) } ``` > The estimate is approximate. The final received amount (`amountTo`) is fixed when the swap is executed and is reported via the swap object and callbacks. **Validation errors** `400 Bad Request` returns the standard validation envelope (see Error format). Common messages: * `Asset from not found` / `Asset to not found` — the asset UUID does not belong to your merchant. * `Unsupported source currency` / `Unsupported target currency` — the currency is not enabled for swaps. * `Native currency not supported as target` — native coins (ETH, BNB, …) cannot be the target asset. * `Unsupported source network` / `Unsupported target network` — the network is not enabled for swaps. * `Min swap amount is ` — the amount is below the minimum swap threshold. * `No route found` — no DEX/CEX route is currently available for this pair and amount. # Create a swap Execute a swap from a previously obtained estimate. The source amount is immediately reserved from the asset’s available balance, and the swap starts processing asynchronously. Track its progress with **Endpoint**\ `POST /2.0/swap/create` **Request body** ```json { "estimateId": "{estimateId}" } ``` | Field | Type | Required | Description | | ------------ | ------ | -------- | ------------------------------------------------------------------- | | `estimateId` | string | yes | UUID returned by Estimate a swap. Valid for 30 minutes, single-use. | **cURL** ```bash curl -X POST "/2.0/swap/create" \ -H "Content-Type: application/json" \ -H "apiKey: " \ -d '{"estimateId":"{estimateId}"}' ``` **Response (200 OK)** ```json { "id": "{swap-uuid}", // Swap ID "amountFrom": "100000000", // Source amount in base units "amountFromInUsd": "100.00", // Source amount in USD (or null) "amountTo": null, // Received amount in base units (null until finished) "amountToInUsd": null, // Received amount in USD (or null) "assetIdFrom": "{assetIdFrom}", // Source merchant asset ID "assetIdTo": "{assetIdTo}", // Target merchant asset ID "cryptoIdFrom": "{cryptoIdFrom}", // Source cryptocurrency ID "cryptoIdTo": "{cryptoIdTo}", // Target cryptocurrency ID "hashFrom": null, // Source transaction hash (null until available) "hashTo": null, // Target transaction hash (null until available) "status": "new", // new | in_progress | finished | rejected "createdAt": "2025-03-11T14:30:16+00:00" // RFC3339, UTC+0 } ``` See Swaps → Swap statuses for the full status lifecycle. **Validation errors** `400 Bad Request` returns the standard validation envelope (see Error format). Common messages: * `Estimate not found` — the estimate is unknown, expired (older than 30 minutes), already used, or does not belong to your merchant. * `Balance not enough` — your available balance for the source asset is lower than the swap amount. # Get a swap Return the current state of a swap by its ID. Poll this endpoint to track progress, or rely on Callbacks to be notified of status changes. **Endpoint**\ `GET /2.0/swap/get` **Query parameters** | Parameter | Type | Required | Description | | --------- | ------ | -------- | ----------------------------- | | `id` | string | yes | UUID of the swap to retrieve. | **cURL** ```bash curl "/2.0/swap/get?id={swap-uuid}" \ -H "apiKey: " ``` **Response (200 OK)** ```json { "id": "{swap-uuid}", // Swap ID "amountFrom": "100000000", // Source amount in base units "amountFromInUsd": "100.00", // Source amount in USD (or null) "amountTo": "99500000", // Received amount in base units (null until finished) "amountToInUsd": "99.50", // Received amount in USD (or null) "assetIdFrom": "{assetIdFrom}", // Source merchant asset ID "assetIdTo": "{assetIdTo}", // Target merchant asset ID "cryptoIdFrom": "{cryptoIdFrom}", // Source cryptocurrency ID "cryptoIdTo": "{cryptoIdTo}", // Target cryptocurrency ID "hashFrom": "0x6d2f...e91a", // Source transaction hash (or null) "hashTo": "0x9a1c...7b30", // Target transaction hash (or null) "status": "finished", // new | in_progress | finished | rejected "fee": { // See API Reference Docs "network": [ { "amount": "2650000000000000", "amountFormatted": "0.00265", "currency": "BNB", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": null, "isChargedToMerchant": false } ], "service": { "amount": "1000000000000000000", "amountFormatted": "1", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.00", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.00" } "createdAt": "2025-03-11T14:30:16+00:00" // RFC3339, UTC+0 } ``` See Swaps → Swap statuses for the full status lifecycle. **Errors** * `404 Not Found` — no swap with this ID belongs to your merchant (the response body is empty). * `403 Forbidden` / `400 Bad Request` / `500 Internal Server Error` — see Error format. # Error format Swap endpoints share the public API error envelopes. The per-endpoint validation messages are listed on each endpoint page. **Missing / invalid API key** ```json { "success": false, "message": "Missing api key", "statusCode": 0 } ``` Include the `apiKey` header in every request. [docs.omypayments.com/api/authentication](https://docs.omypayments.com/api/authentication) **Validation error (`400 Bad Request`)** ```json { "success": false, "message": "Validation error", "errors": [ { "field": "amount", "messages": ["Invalid value format"] } ] } ``` **No permission (`403 Forbidden`)** The API key does not have the **swap** permission enabled. ```json { "success": false, "message": "You have no permissions for this action", "statusCode": 403 } ``` **Internal error (`500`)** ```json { "success": false, "message": "Internal Server Error", "statusCode": 500 } ``` # Mass Payouts Programmatically create payout lists, add recipients, and launch a distribution run. This page documents the HTTP endpoints you’ll call from your backend. Authentication and error-envelope format follow the public API style. > **Base URL**: `https://api.omypayments.com`\ > **Version**: `v2` (all endpoints below start with `/2.0/...`)\ > **Auth**: add your API key in the header: `apiKey: ` **Prerequisites** * Make sure the tokens you intend to use are enabled/configured in **Assets** (dashboard). * When preparing `amount` values for token payouts, use the token’s base units (see `crypto.decimals` on the “Get Merchant Asset Data” endpoint to convert, if needed). # Create a payout (container) Create an empty payout container bound to a specific asset (network+token). **Endpoint**\ `POST /2.0/mass-payout/create-payout` **Request body** ```json { "assetId": "be2ed9e3-f8c7-4f38-b99b-ef6f9c3cfae8", "name": "September payroll" } ``` **cURL** ```bash curl -X POST "https://api.omypayments.com/2.0/mass-payout/create-payout" \ -H "Content-Type: application/json" \ -H "apiKey: " \ -d '{"assetId":"be2ed9e3-f8c7-4f38-b99b-ef6f9c3cfae8","name":"September payroll"}' ``` # Rename a payout **Endpoint**\ `POST /2.0/mass-payout/update-payout` **Request body** ```json { "id": "92b482eb-6ddb-4da7-95d4-582a69e18082", "name": "Payroll — Sep 2025" } ``` # Delete a payout **Endpoint**\ `POST /2.0/mass-payout/delete-payout` **Request body** ```json { "id": "92b482eb-6ddb-4da7-95d4-582a69e18082" } ``` # Add a recipient (target) Append a recipient row to a payout. **Endpoint**\ `POST /2.0/mass-payout/create-target` **Request body** ```json { "payoutId": "92b482eb-6ddb-4da7-95d4-582a69e18082", "address": "0x000000000000000000000000000000000000dEaD", "amount": "1000000", "comment": "Vasya Pupkin" } ``` **Notes** * `amount` is a string. For tokens with decimals, use base units (see `crypto.decimals` on the asset data endpoint). # Update a recipient Change the `amount` and/or `comment` for a row. **Endpoint**\ `POST /2.0/mass-payout/update-target` **Request body** ```json { "id": "1615dd7e-c116-4bb0-aea9-7f915580a93f", "amount": "2000000", "comment": "Ivan Ivanov" } ``` # Delete a recipient **Endpoint**\ `POST /2.0/mass-payout/delete-target` **Request body** ```json { "id": "1615dd7e-c116-4bb0-aea9-7f915580a93f" } ``` # Start a payout run (create task) Launches the on-chain distribution for the given payout. **Endpoint**\ `POST /2.0/mass-payout/create-task` **Request body** ```json { "payoutId": "92b482eb-6ddb-4da7-95d4-582a69e18082" } ``` **Typical flow** 1. `create-payout` 2. add `create-target` rows 3. `create-task` 4. `mass-payout/tasks` # List tasks `GET /2.0/mass-payout/tasks` Your payout tasks, newest first. **Permission:** `can_payout`. | Query parameter | Type | Meaning | | --------------- | -------- | ------------------------------------------------------ | | `cursor` | `string` | Page cursor from a previous response | | `status` | `string` | `pending` \| `failed` \| `success` | | `assetId` | UUID | Filter by asset | | `payoutId` | UUID | Filter by the parent payout | | `createdAtFrom` | `string` | ISO-8601 with offset, e.g. `2026-07-01T00:00:00+00:00` | | `createdAtTo` | `string` | Same format | Page size is fixed at **50**. #### Response `200` ```json { "data": [ { "id": "{uuid}", "type": "multi_tx", "status": "success", "subStatus": "payout_sent", "payoutId": "{payoutId}", "amount": "100000000000000000000", "amountInUsd": "100.00", "assetId": "5c3767ab-220c-4fce-b3af-20ffcf2d2729", "crypto": { "id": "{cryptoId}", "title": "Binance Pegged USDT", "symbol": "USDT", "contractAddress": "0x0000000000000000000000000000000000000000", "decimals": 18, "logoURI": "https://raw.githubusercontent.com/0xsquid/assets/main/images/tokens/usdt.svg" }, "network": { "id": "{networkId}", "title": "BNB Chain", "symbol": "BSC", "chainId": "56", "networkType": "evm" }, "transferTxHash": "{transferTxHash}", "payoutTxHash": "{payoutTxHash}", "targetsCount": 4, "fee": { "network": [ { "amount": "2650000000000000", "amountFormatted": "0.00265", "currency": "BNB", "cryptoId": "75608cde-155c-4550-8025-cddf01bf2289", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": null, "isChargedToMerchant": false } ], "service": { "amount": "1000000000000000000", "amountFormatted": "1", "currency": "USDT", "cryptoId": "1fa107f9-3832-4286-9c72-493eaf675da5", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": "1.00", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.00" }, "createdAt": "2026-07-28T10:53:41+00:00" } ], "cursorPrevious": null, "cursorNext": "c3c5VkZFbFppODFqYmllZDczTkgzTHE2d1hZOXZlVC9ma1NaMTNPejI2dz0=" } ``` Pass `cursorNext` back as `?cursor=…` for the next page. A `null` cursor means there is no page in that direction. 🔴 The merchant scope comes from your apiKey. A `merchantId` query parameter has no effect. # Get a task `GET /2.0/mass-payout/task?id={uuid}` One payout task of yours, by id. **Permission:** `can_payout`. | Query parameter | Required | Type | | --------------- | -------- | ---- | | `id` | yes | UUID | #### Response `200` ```json { "id": "{uuid}", "type": "multi_tx", "status": "success", "subStatus": "payout_sent", "payoutId": "{payoutId}", "amount": "100000000000000000000", "amountInUsd": "100.00", "assetId": "5c3767ab-220c-4fce-b3af-20ffcf2d2729", "crypto": { "id": "{cryptoId}", "title": "Binance Pegged USDT", "symbol": "USDT", "contractAddress": "0x0000000000000000000000000000000000000000", "decimals": 18, "logoURI": "https://raw.githubusercontent.com/0xsquid/assets/main/images/tokens/usdt.svg" }, "network": { "id": "{networkId}", "title": "BNB Chain", "symbol": "BSC", "chainId": "56", "networkType": "evm" }, "transferTxHash": "{transferTxHash}", "payoutTxHash": "{payoutTxHash}", "targetsCount": 4, "fee": { "network": [ { "amount": "2650000000000000", "amountFormatted": "0.00265", "currency": "BNB", "cryptoId": "75608cde-155c-4550-8025-cddf01bf2289", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": null, "isChargedToMerchant": false } ], "service": { "amount": "1000000000000000000", "amountFormatted": "1", "currency": "USDT", "cryptoId": "1fa107f9-3832-4286-9c72-493eaf675da5", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": "1.00", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.00" }, "createdAt": "2026-07-28T10:53:41+00:00" } ``` `type`: `single_tx` | `multi_tx`. `status`: `pending` | `failed` | `success`. The single network leg is the **sum of all gas of the task**: the transfer transaction, the payout transaction, and the per-target transactions. It carries `amountInUsd: null` and `isChargedToMerchant: false` - that gas is spent from your own payment address (which the Gas Manager funds), we never priced it in USD, and it is not part of `totalInUsd`. To see what the gas supply itself cost you, read `gas-manager/list`. #### Codes Same as `deposit/get`, with `can_payout` instead of `can_invoice`. # Error format On errors, the API returns a standard JSON envelope, for example: ```json { "success": false, "message": "Missing api key", "statusCode": 0 } ``` Ensure you include the `apiKey` header in every request. [docs.omypayments.com](https://docs.omypayments.com/api/authentication) # Withdrawals Send funds from your merchant assets to on-chain addresses and track each withdrawal to completion. This page documents the HTTP endpoints you’ll call from your backend. Authentication and the error-envelope format follow the public API style. > **Base URL**: `https://api.omypayments.com`\ > **Version**: `v1` (all endpoints below start with `/1.0/...`)\ > **Auth**: add your API key in the header: `apiKey: `\ > **Permission**: the API key must have the **withdrawal** permission enabled, otherwise requests are rejected with `403 Forbidden`. Listing withdrawals additionally accepts the **invoice** permission. **Prerequisites** * API withdrawals must be enabled for your merchant account (otherwise `400` with `API withdrawals are currently inactive`). * `amount` is expressed in the token’s base units (integer string, no decimal point). For a token with 6 decimals, `100` = `"100000000"` — see `crypto.decimals` on the “Get Merchant Asset Data” endpoint to convert. * Each withdrawal must meet the per-crypto **minimum USD amount**, and the asset must have enough available balance to cover `amount` plus the system fee (for API withdrawals the fee is always paid by the sender). * The destination `address` is optional: if omitted, the asset’s **default wallet** is used. The address must be valid for the asset’s network and — when a **whitelist** is enabled for your merchant — must be whitelisted. Destinations are also screened against our AML policy. **Typical flow** 1. `asset-withdrawal` (reserves funds, starts processing) 2. `asset-withdrawal-info` and/or `asset-withdrawals` and/or callbacks to track status. **Withdrawal statuses** | Status | Meaning | | --------- | ------------------------------------------------------------------------------------------------------------------ | | `pending` | Withdrawal created, funds reserved from the available balance, awaiting/processing the on-chain send. | | `success` | Withdrawal sent on-chain; `txHash` is populated. | | `failed` | Withdrawal was declined or the transaction was reverted; the reserved funds are returned to the available balance. | *** # Withdraw an asset Send funds from one of your merchant assets to an on-chain address. The requested amount (plus the system fee, see payer below) is immediately reserved from the asset’s available balance, and the with **Endpoint**\ `POST /1.0/merchant/asset-withdrawal` **Prerequisites** * API withdrawals must be enabled for your merchant account (otherwise `400` with `API withdrawals are currently inactive`). * `amount` is expressed in the token’s base units (integer string, no decimal point). For a token with 6 decimals, `100` = `"100000000"` — see `crypto.decimals` on the Get Merchant Asset Data endpoint to convert. * The withdrawal must meet the per-crypto **minimum USD amount**; amounts below it are rejected. **Request body** ```json { "assetId": "87d68a49-4b0c-4b4c-ad07-4f39aa4a39ab", "amount": "60000000000000000000", "address": "0x1111111111111111111111111111111111111111" } ``` | Field | Type | Required | Description | | --------- | ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `assetId` | string | yes | UUID of the merchant asset to withdraw from. | | `amount` | string | yes | Withdrawal amount in the token’s base units (integer string). | | `address` | string | no | Destination address. **If omitted (or `null`), the asset’s default wallet is used** (configure it in **Assets** → *wallet*). If neither is provided, the request is rejected. The address must be valid for the asset’s network; if a **whitelist** is enabled for your merchant, the address must be whitelisted. | > **Note on `payer`.** For API-created withdrawals the fee payer is always the **sender**: the system fee is added on top of `amount` and debited from your available balance, and the recipient receives exactly `amount`. `payer` is not an input parameter of this endpoint; it is returned in the response for reference. **cURL** ```bash curl -X POST "https://api.omypayments.com/1.0/merchant/asset-withdrawal" \ -H "Content-Type: application/json" \ -H "apiKey: " \ -d '{"assetId":"87d68a49-4b0c-4b4c-ad07-4f39aa4a39ab","amount":"60000000000000000000","address":"0x1111111111111111111111111111111111111111"}' ``` **Response (200 OK)** ```json { "id": "{uuid}", // Withdrawal ID "status": "pending", // pending | success | failed "address": "0x1111111111111111111111111111111111111111", // Destination address (the provided one, or the asset's default wallet) "amount": "60000000000000000000", // Requested amount in base units "amountInUsd": "60.00", // Requested amount in USD "payer": "sender", // Fee payer (always "sender" for API withdrawals) "isPrivate": false, // Whether this is a private withdrawal "asset": { "id": "{assetId}", // Merchant asset ID "balance": "99940000000000000000000", // Asset available balance (base units) after reservation "balanceInUsd": "99940", // Asset available balance in USD "wallet": "0x1111111111111111111111111111111111111111" // Asset default wallet (or null) }, "crypto": { "id": "{cryptoId}", // Cryptocurrency ID "title": "Binance Pegged USDT", "symbol": "USDT", "contractAddress": "0x1111111111111111111111111111111111111111", // null for native coins "decimals": 18, "logoURI": "https://.../usdt.svg" }, "network": { "id": "{networkId}", // Network ID "title": "BNB Chain", "symbol": "BSC", "chainId": "56", // External chain id (string) "networkType": "evm" }, "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "txHash": null, // On-chain transaction hash (null until the withdrawal is sent) "createdAt": "2026-07-11 10:28:58" // UTC, "Y-m-d H:i:s" } ``` A freshly created withdrawal starts as `pending`. It transitions to `success` once sent on-chain, or `failed` if it is declined or the transaction is reverted. Track it via Get a withdrawal or callbacks. **Validation errors** `400 Bad Request` returns the standard validation envelope (see Error format): ```json { "success": false, "message": "Input validation error.", "statusCode": 400, "errors": [ { "field": "address", "messages": ["Please, provide the address. To use default - edit your asset and create wallet address"] } ] } ``` Common messages: * `Please, provide the address. To use default - edit your asset and create wallet address` — `address` was omitted and the asset has no default wallet. * `The provided address is not valid` — the address is not a valid format for the asset’s network. * `The provided address is not in whitelist` — a whitelist is enabled and the address is not on it. * `API withdrawals are currently inactive` — API withdrawals are disabled for your merchant. * `Insufficient balance` — the asset’s available balance is lower than `amount` + fee. * `Minimum withdrawal amount is {amount}` — below the per-crypto minimum. * `You have reached withdrawal limit` / `Maximum amount is {amount}` — a merchant withdrawal limit was reached. * `Withdrawal is temporary unavailable` — withdrawals for this crypto/network are temporarily disabled. * `Withdrawal amount must be greater than fee` — the amount does not cover the system fee. * `Private payment is unavailable` — `isPrivate` was requested but the network does not support it. * `Withdrawals to your wallet are not possible as they do not comply with our AML policy. Please enter a different address` — the destination address failed the AML risk check. Other status codes: * `401 Unauthorized` — missing `apiKey` header. * `403 Forbidden` — the API key lacks the **withdrawal** permission. *** # Get a withdrawal Return the current state of a withdrawal by its ID. Poll this endpoint to track progress, or rely on callbacks to be notified of status changes. **Endpoint**\ `GET /1.0/merchant/asset-withdrawal-info` **Query parameters** | Parameter | Type | Required | Description | | --------- | ------ | -------- | ----------------------------------- | | `id` | string | yes | UUID of the withdrawal to retrieve. | **cURL** ```bash curl "https://api.omypayments.com/1.0/merchant/asset-withdrawal-info?id=85c8d15e-fa47-4219-8d91-175fc91685a2" \ -H "apiKey: " ``` **Response (200 OK)** The response body is identical to the Withdraw an asset response: ```json { "id": "85c8d15e-fa47-4219-8d91-175fc91685a2", // Withdrawal ID "status": "pending", // pending | success | failed "address": "0x1111111111111111111111111111111111111111", // Destination address "amount": "60000000000000000000", // Requested amount in base units "amountInUsd": "60.00", // Requested amount in USD "payer": "sender", // Fee payer (always "sender" for API withdrawals) "isPrivate": false, // Whether this is a private withdrawal "asset": { "id": "87d68a49-4b0c-4b4c-ad07-4f39aa4a39ab", // Merchant asset ID "balance": "99880000000000000000000", // Asset available balance (base units) "balanceInUsd": "99880", // Asset available balance in USD "wallet": "0x89B177488596b79520ab581a427AE42f6A1B49E9" // Asset default wallet (or null) }, "crypto": { "id": "1fa107f9-3832-4286-9c72-493eaf675da5", // Cryptocurrency ID "title": "Binance Pegged USDT", "symbol": "USDT", "contractAddress": "0x55d398326f99059fF775485246999027B3197955", // null for native coins "decimals": 18, "logoURI": "https://.../usdt.svg" }, "network": { "id": "e130ce89-1d4d-4951-beaf-465ec43cf399", // Network ID "title": "BNB Chain", "symbol": "BSC", "chainId": "56", // External chain id (string) "networkType": "evm" }, "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "txHash": null, // On-chain transaction hash (null until the withdrawal is sent) "createdAt": "2026-07-11 10:28:58" // UTC, "Y-m-d H:i:s" } ``` A withdrawal starts as `pending`, then transitions to `success` (sent on-chain) or `failed` (declined or reverted). **Errors** * `404 Not Found` — no withdrawal with this ID belongs to your merchant (the response body is empty). * `400 Bad Request` — `id` is missing or not a valid UUID (standard validation envelope, see Error format): ```json { "success": false, "message": "Input validation error.", "statusCode": 400, "errors": [{ "field": "id", "messages": ["Invalid UUID format"] }] } ``` * `401 Unauthorized` — missing `apiKey` header. * `403 Forbidden` — the API key lacks the **withdrawal** permission. *** # List withdrawals Return a paginated list of your merchant’s withdrawals, newest first. Use it to reconcile withdrawals or to poll recent activity; for a single withdrawal use Get a withdrawal. **Endpoint**\ `GET /1.0/merchant/asset-withdrawals` **Query parameters** | Parameter | Type | Required | Description | | --------- | ------- | -------- | ---------------------------------------------- | | `page` | integer | no | Page number, starting at `1`. Defaults to `1`. | | `perPage` | integer | no | Items per page. Defaults to `10`. | **cURL** ```bash curl "https://api.omypayments.com/1.0/merchant/asset-withdrawals?page=1&perPage=10" \ -H "apiKey: " ``` **Response (200 OK)** ```json { "totalCount": 42, // Total number of withdrawals for your merchant "page": 1, // Current page "perPage": 10, // Items per page "data": [ // Withdrawals on this page { "id": "85c8d15e-fa47-4219-8d91-175fc91685a2", // Withdrawal ID "status": "success", // pending | success | failed "address": "0x1111111111111111111111111111111111111111", // Destination address "amount": "60000000000000000000", // Requested amount in base units "amountInUsd": "60.00", // Requested amount in USD "payer": "sender", // Fee payer (always "sender" for API withdrawals) "isPrivate": false, // Whether this is a private withdrawal "asset": { "id": "87d68a49-4b0c-4b4c-ad07-4f39aa4a39ab", // Merchant asset ID "balance": "99880000000000000000000", // Asset available balance (base units) "balanceInUsd": "99880", // Asset available balance in USD "wallet": "0x89B177488596b79520ab581a427AE42f6A1B49E9" // Asset default wallet (or null) }, "crypto": { "id": "1fa107f9-3832-4286-9c72-493eaf675da5", // Cryptocurrency ID "title": "Binance Pegged USDT", "symbol": "USDT", "contractAddress": "0x55d398326f99059fF775485246999027B3197955", // null for native coins "decimals": 18, "logoURI": "https://.../usdt.svg" }, "network": { "id": "e130ce89-1d4d-4951-beaf-465ec43cf399", // Network ID "title": "BNB Chain", "symbol": "BSC", "chainId": "56", // External chain id (string) "networkType": "evm" }, "fee": { "network": null, "service": { "amount": "1050000000000000000", "amountFormatted": "1.05", "currency": "USDT", "cryptoId": "{cryptoId}", "networkId": "{networkId}", "amountInUsd": "1.05", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.05" }, "txHash": "0xabc123...", // On-chain transaction hash (null until the withdrawal is sent) "createdAt": "2026-07-11 10:28:58" // UTC, "Y-m-d H:i:s" } ] } ``` Each item in `data` has the same shape as the Withdraw an asset response. **Errors** * `401 Unauthorized` — missing `apiKey` header. * `403 Forbidden` — the API key lacks both the **withdrawal** and the **invoice** permission. *** # Gas Manager `GET /2.0/gas-manager/list` The history of your Gas Manager operations, with our fee on each one. ### What the Gas Manager does Your payment addresses need the network's native coin to send transactions from. The Gas Manager keeps them topped up: it takes stablecoins from your **gas liquidity address**, converts them, and credits native coin to whichever of your payment addresses is running low. Two consequences worth knowing before reading the response: * These operations **do not pass through your asset balances**. Nothing here appears in `internal-transaction/list`; the stablecoins are spent from the gas liquidity address, not from an asset. The three gas opcodes you may see in the ledger (`withdrawal-gas`, and the deposit / invoice refund gas ones) are a completely different mechanism and never show up in this list. * The unit of this list is a **distribution** - one top-up of one address - not a pipeline. One pipeline (one purchase of native coin) usually feeds several distributions. ### Reading one row ```json { "id": "0848e093-bb67-4e06-b89a-c051a0408f57", "status": "success", "subStatus": "sent", "network": {"id": "e130ce89-1d4d-4951-beaf-465ec43cf399", "title": "BNB Chain", "symbol": "BSC"}, "targetAddress": "0x8139BC460c0Ff40850fA69026910a0713699E516", "txHash": "cspt2801-gas-a-1", "topUp": { "amount": "4000000000000000", "amountFormatted": "0.004", "currency": "BNB", "cryptoId": "75608cde-155c-4550-8025-cddf01bf2289", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": "12.00", "isChargedToMerchant": false }, "charged": { "amount": "13200000000000000000", "amountFormatted": "13.2", "currency": "USDT", "cryptoId": "1fa107f9-3832-4286-9c72-493eaf675da5", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": "13.20", "isChargedToMerchant": true }, "fee": { "network": null, "service": { "amount": "1200000000000000000", "amountFormatted": "1.2", "currency": "USDT", "cryptoId": "1fa107f9-3832-4286-9c72-493eaf675da5", "networkId": "e130ce89-1d4d-4951-beaf-465ec43cf399", "amountInUsd": "1.20", "isChargedToMerchant": true }, "exchange": null, "totalInUsd": "1.20" }, "pipeline": { "id": "f1000000-0000-0000-0000-000000000001", "status": "finished", "totalAmountInUsd": "36.00", "createdAt": "2026-07-28T11:17:25+00:00" }, "createdAt": "2026-07-28T11:17:15+00:00", "updatedAt": "2026-07-28T11:17:25+00:00" } ``` #### `charged` vs `topUp` vs `fee.service` These three are easy to confuse. They answer different questions. | Field | Question it answers | Currency | Charged to you | | ------------- | --------------------------------------------------------- | -------------------------- | ------------------------------ | | `topUp` | How much native coin was **credited to your address**? | native coin of the network | no - this is what you received | | `charged` | How much was **debited from your gas liquidity address**? | your donor stablecoin | yes | | `fee.service` | How much of that debit was **our fee**? | your donor stablecoin | yes | The relationship: `charged = value of the top-up + fee.service`. In the example above, `13.2 USDT = 12.00 (the 0.004 BNB you received) + 1.20 (our fee)`. `fee.network` is always `null` here: the gas of the distributing transaction itself burns on **our** sender address and is not billed to you. `fee.totalInUsd` equals `fee.service.amountInUsd` - our fee is the only thing in the fee object. #### The `pipeline` block A compact view of the batch this distribution belonged to: `id`, `status`, `totalAmountInUsd`, `createdAt`. Deliberately nothing else - the liquidity-side details of how we sourced the native coin are internal. #### Statuses `status`: `pending`, `cancelled`, `failed`, `success`. `subStatus` carries the finer state within the pipeline (`sent`, `enough_balance`, `not_enough_donor_balance`, …) and may be `null`. ### 🔴 Cancelled operations are hidden by default A distribution is cancelled when the top-up turned out to be unnecessary - typically the address already had enough gas (`sub_status: enough_balance`) or its balance could not be determined (`undefined_balance`). Nothing was sent, nothing was charged, and such rows carry `charged: null`, `topUp: null` and `fee.service: null`. **They are excluded from the default listing** so they do not pad your pages with rows that cost nothing. To see them, ask explicitly: ``` GET /2.0/gas-manager/list?status=cancelled ``` This is the only filtering the endpoint applies on its own. Everything else you see is everything there is. ### Request ``` GET /2.0/gas-manager/list apiKey: ``` | Query parameter | Type | Meaning | | --------------- | -------- | ------------------------------------------------------------------------------ | | `cursor` | `string` | Page cursor, taken from `cursorNext` / `cursorPrevious` of a previous response | | `status` | `string` | One of `pending`, `cancelled`, `failed`, `success` | | `networkId` | `string` | Our network identifier | | `createdAtFrom` | `string` | ISO-8601 with offset, e.g. `2026-07-01T00:00:00+00:00` | | `createdAtTo` | `string` | Same format | Page size is fixed at **50**. The response shape is `{data, cursorPrevious, cursorNext}`; a `null` cursor means there is no page in that direction. ### Permissions Requires **`can_invoice`** - the same permission that guards deposits. The endpoint returns `targetAddress`, a real on-chain payment address of yours, together with the hash of every top-up, and `can_invoice` is the flag that already governs access to those addresses. It only ever returns your own merchant's operations; the scope comes from the apiKey and cannot be influenced by any query parameter. ### Response codes | Code | When | | ----- | ------------------------------------------ | | `200` | OK | | `400` | Invalid `status` value or malformed date | | `401` | Missing or invalid `apiKey` | | `403` | The apiKey has no `can_invoice` permission | | `429` | Rate limit (50 requests per second) | # Callbacks OmyPayments notifies your backend by calling your \*\*Callback URL\*\* whenever an entity changes status. Set the Callback URL in your account settings. **Requirements** * Your endpoint must be publicly accessible and return a `200` HTTP status code on receipt. * The same endpoint receives every callback type. Route by payload shape: invoice callbacks carry `usdAmount` / `productTitle`; swap callbacks carry `status` in the form `new | in_progress | finished | rejected` together with `cryptoFrom` / `cryptoTo`. *** ### Invoice Callbacks Sent every time an invoice changes status. **Payload** ```json { "id": "UUID", // Invoice ID "usdAmount": "100.00", // Invoice amount in USD "status": "pending", // Invoice status "productTitle": "Test Product", // Product title "extraData": null, // Additional invoice information. "cryptoAmount": "0", // Amount in selected cryptocurrency (or null if not chosen) "crypto": { // Cryptocurrency data (or null if not chosen) "id": "uuid", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT", // Crypto symbol "contractAddress": "0x0000000000000000000000000000000000000000", // Crypto contract address "decimals": 6, // Crypto decimals "logoURI": "https://..." // Crypto logo URI }, "network": { // Network data (or null if not chosen) "id": "UUID", // Network UUID "chainId": "56", // Network chain ID "symbol": "BSC", // Network symbol "name": "BNB Chain", // Network title "networkType": "evm" // Network type }, "address": "0x0000000000000000000000000000000000000000", // Payment address (or null if not chosen) "expiredAt": "2025-01-01 00:00:00", // Invoice expiration datetime (UTC+0) "transfer": { // Payment transaction details (or null if not available) "from": "0x0000000000000000000000000000000000000000", // Transfer from address "hash": "0x0000000000000000000000000000000000000000000000000000000000000000" // Transfer hash }, "signature": "sha256=" // HMAC-SHA256 signature - see "Verifying webhook signatures" below } ``` *** ### Swap Callbacks Sent every time a swap changes status. Each callback carries an event type in the form `swap.`: | Event | Sent when | | ------------------ | ------------------------------------------------------------------- | | `swap.new` | A swap was created and funds were reserved. | | `swap.in_progress` | The swap started executing on-chain / via the routing provider. | | `swap.finished` | The swap completed successfully (`amountTo`, `hashTo` populated). | | `swap.rejected` | The swap failed; reserved funds were returned to available balance. | **Payload** ```json { "id": "UUID", // Swap ID "amountFrom": "100000000", // Source amount in base units "amountFromInUsd": "100.00", // Source amount in USD (or null) "amountTo": "99500000", // Received amount in base units (or null) "amountToInUsd": "99.50", // Received amount in USD (or null) "hashFrom": "0x...", // Source transaction hash (or null) "hashTo": "0x...", // Target transaction hash (or null) "status": "finished", // Swap status: new | in_progress | finished | rejected "createdAt": "2025-03-11T14:30:16+00:00", // Swap creation datetime (RFC3339, UTC+0) "cryptoFrom": { // Source cryptocurrency data "id": "UUID", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT", // Crypto symbol "decimals": 6, // Crypto decimals "contractAddress": "0x0000000000000000000000000000000000000000", // Contract address (or null for native) "logoUrl": "https://..." // Crypto logo URL (or null) }, "cryptoTo": { // Target cryptocurrency data "id": "UUID", "title": "USD Coin", "symbol": "USDC", "decimals": 6, "contractAddress": "0x0000000000000000000000000000000000000000", "logoUrl": "https://..." }, "networkFrom": { // Source network data "id": "UUID", // Network UUID "title": "BNB Chain", // Network title "symbol": "BSC" // Network symbol }, "networkTo": { // Target network data "id": "UUID", "title": "Polygon", "symbol": "MATIC" }, "signature": "sha256=" // HMAC-SHA256 signature - see "Verifying webhook signatures" below } ``` > Amounts (`amountFrom`, `amountTo`) are returned in the cryptocurrency's base units. Use the matching `decimals` value to convert to a human-readable amount. The `amountTo` / `hashTo` fields are populated once the swap reaches the `finished` status. *** ### Withdrawal Callbacks Sent every time a withdrawal changes its **main** status. Each callback carries an event type in the form `withdrawal.`: | Event | Sent when | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `withdrawal.pending` | A withdrawal was created and funds were reserved from your asset balance. | | `withdrawal.success` | The withdrawal was sent on-chain successfully (`txHash` populated). | | `withdrawal.failed` | The withdrawal was declined, or its transaction reverted / timed out; reserved funds were returned to your available balance. | > **Only main-status changes are delivered.** Intermediate states of a withdrawal (e.g. `accepted`, `sending`, `sent`) do **not** trigger a callback, and the payload does **not** include a sub-status field. A given withdrawal therefore emits at most one `withdrawal.pending`, followed by exactly one terminal `withdrawal.success` **or** `withdrawal.failed`. **Payload** ```json { "id": "UUID", // Withdrawal ID "status": "pending", // Withdrawal main status: pending | success | failed "address": "0x0000000000000000000000000000000000000000", // Destination address "amount": "60000000000000000000", // Amount in base units "amountInUsd": "60.00", // Amount in USD "payer": "sender", // Fee payer (always "sender" for API withdrawals) "isPrivate": false, // Whether this is a private withdrawal "txHash": null, // On-chain transaction hash (null until sent; returned as-is, no masking) "crypto": { // Cryptocurrency data "id": "UUID", // Crypto UUID "title": "Tether USD", // Crypto title "symbol": "USDT", // Crypto symbol "decimals": 18, // Crypto decimals "contractAddress": "0x0000000000000000000000000000000000000000", // Contract address (or null for native) "logoUrl": "https://..." // Crypto logo URL (or null) }, "network": { // Network data "id": "UUID", // Network UUID "title": "BNB Chain", // Network title "symbol": "BSC" // Network symbol }, "createdAt": "2025-03-11T14:30:16+00:00", // Withdrawal creation datetime (RFC3339, UTC+0) "signature": "sha256=" // HMAC-SHA256 signature — see "Verifying webhook signatures" below } ``` > `amount` is returned in the cryptocurrency's base units — use the matching `crypto.decimals` value to convert to a human-readable amount. The payload is intentionally lean; for the full withdrawal details (fees, gas breakdown) query Get a withdrawal by `id`. *** ### Verifying webhook signatures Every callback includes a `signature` field in the root of the payload: ``` sha256=79aa19a4d3bf6691205e5c6506530135484207234bf4a66cd265a1437f2ef3a4 ``` Verifying this field lets you confirm that the callback was sent by OmyPayments and that no field was modified in transit. #### Getting your webhook secret Find your webhook secret in the merchant dashboard on the **Profile** page, in the **API keys** section. Use the **Regenerate** button if you need to rotate it. Keep the secret server-side - never expose it to a browser or include it in client code. #### How the signature is computed The signature is `HMAC-SHA256` over the **canonicalized payload** (the full callback body with the `signature` field removed), prefixed with `sha256=`: ``` signature = "sha256=" + lowercase_hex( HMAC_SHA256(key=webhook_secret, msg=canonical(payload)) ) ``` **Canonicalization algorithm:** 1. Remove the `signature` field from the payload. 2. Recursively drop `null` values from both objects and arrays: * **Objects:** remove every key whose value is `null`; recurse into non-null values. Drop the entire object if all keys are removed. * **Arrays:** remove every `null` element; recurse into non-null elements. Element order is preserved; the array is re-indexed after removal. 3. Serialize the result to JSON with: * Keys sorted by Unicode code point (ascending); all keys are ASCII, so this is plain lexicographic order. * Compact format - separators `,` and `:`, no spaces. * Strings in raw UTF-8: non-ASCII characters are **not** escaped to `\uXXXX`; only `"` → `\"`, `\` → `\\`, and C0 control characters are escaped. The characters `/`, `<`, `>`, `&` are **not** escaped. * Integer fields (e.g., `decimals`) serialized as-is (`6`, `18`); all monetary amounts are strings. #### Test vectors Use these vectors to validate your implementation. Secret for all three: ``` whsec_test_2c5f9b8e4a1d7063f5e2c9a0b3d6e8f1a4c7b0d3 ``` **Vector 1 - `invoice.completed`, full payload (Unicode in `productTitle`, JSON string in `extraData`)** Canonical string: ``` {"address":"0x1234567890AbCdEf1234567890aBcDeF12345678","createdAt":"2026-06-15 12:00:00","crypto":{"contractAddress":"0xdAC17F958D2ee523a2206206994597C13D831ec7","decimals":6,"id":"2c1d8f6a-7b3e-4d9c-a1f0-5e2b8c4d7a90","logoURI":"https://assets.omypayments.com/usdt.png","name":"Tether USD","symbol":"USDT"},"cryptoAmount":"100.500000","expiredAt":"2026-06-15 12:30:00","extraData":"{\"orderId\":42}","id":"9b7e2c41-0f3a-4c8e-bb11-2f0a9d6e1234","network":{"chainId":"1","id":"1f0e3a2b-4c5d-6e7f-8a9b-0c1d2e3f4a5b","name":"Ethereum","networkType":"evm","symbol":"ETH"},"productTitle":"Café Münchén — Order #42","status":"completed","transfer":{"from":"0xAbC0000000000000000000000000000000000001","hash":"0xdeadbeefcafebabe0000000000000000000000000000000000000000deadbeef"},"usdAmount":"100.50"} ``` Expected signature: ``` sha256=79aa19a4d3bf6691205e5c6506530135484207234bf4a66cd265a1437f2ef3a4 ``` **Vector 2 - `invoice.pending`, minimal (all nullable fields are null → dropped)** Canonical string: ``` {"createdAt":"2026-06-15 12:45:00","expiredAt":"2026-06-15 13:00:00","id":"3d2c1b0a-9f8e-7d6c-5b4a-3c2d1e0f9a8b","status":"pending","usdAmount":"49.99"} ``` Expected signature: ``` sha256=364b6d1f542907e1845e2bf78af2a7aa33a37f0233ff200e139f05df2c79ef8d ``` **Vector 3 - `swap.completed` (`hashTo` is null → dropped; `createdAt` in RFC3339)** Canonical string: ``` {"amountFrom":"1.000000000000000000","amountFromInUsd":"3500.00","amountTo":"3490.250000","amountToInUsd":"3490.25","createdAt":"2026-06-15T12:00:00+00:00","cryptoFrom":{"decimals":18,"id":"aa11bb22-cc33-dd44-ee55-ff6677889900","logoUrl":"https://assets.omypayments.com/eth.png","symbol":"ETH","title":"Ethereum"},"cryptoTo":{"contractAddress":"0xdAC17F958D2ee523a2206206994597C13D831ec7","decimals":6,"id":"2c1d8f6a-7b3e-4d9c-a1f0-5e2b8c4d7a90","logoUrl":"https://assets.omypayments.com/usdt.png","symbol":"USDT","title":"Tether USD"},"hashFrom":"0x1111111111111111111111111111111111111111111111111111111111111111","id":"7a6b5c4d-3e2f-1a0b-9c8d-7e6f5a4b3c2d","networkFrom":{"id":"1f0e3a2b-4c5d-6e7f-8a9b-0c1d2e3f4a5b","symbol":"ETH","title":"Ethereum"},"networkTo":{"id":"1f0e3a2b-4c5d-6e7f-8a9b-0c1d2e3f4a5b","symbol":"ETH","title":"Ethereum"},"status":"completed"} ``` Expected signature: ``` sha256=729cc144f824a2b2de4bac765251b47298b192a437abbed92a9b14e67712fc33 ``` #### Verification examples The following examples are verified against all three test vectors above. **Python** ```python import hashlib import hmac import json def _drop_null(obj): if isinstance(obj, dict): result = {} for k, v in obj.items(): cleaned = _drop_null(v) if cleaned is not None: result[k] = cleaned return result if result else None if isinstance(obj, list): return [_drop_null(v) for v in obj if v is not None] return obj def _canonical(payload: dict) -> str: cleaned = _drop_null(payload) return json.dumps(cleaned, sort_keys=True, separators=(',', ':'), ensure_ascii=False) def verify_signature(payload: dict, secret: str, signature: str) -> bool: """Verify an OmyPayments webhook signature. Remove the 'signature' field from the parsed payload before calling this function. """ without_sig = {k: v for k, v in payload.items() if k != 'signature'} expected = 'sha256=' + hmac.new( secret.encode('utf-8'), _canonical(without_sig).encode('utf-8'), hashlib.sha256, ).hexdigest() return hmac.compare_digest(expected, signature) ``` **Usage:** ```python import json raw_body = request.body # bytes from HTTP request payload = json.loads(raw_body) signature = payload.get('signature', '') if not verify_signature(payload, WEBHOOK_SECRET, signature): return HttpResponse(status=403) # safe to process invoice_id = payload['id'] ``` **Language notes:** `json.dumps` with `sort_keys=True` and `separators=(',',':')` handles key sorting and compact format. `ensure_ascii=False` outputs UTF-8 directly without `\uXXXX` escaping. `hmac.compare_digest` provides constant-time comparison. *** **JavaScript / Node.js** ```javascript const crypto = require('crypto'); function _dropNull(obj) { if (obj === null || obj === undefined) return undefined; if (Array.isArray(obj)) { return obj .filter(v => v !== null && v !== undefined) .map(_dropNull); } if (typeof obj !== 'object') return obj; const result = {}; for (const [k, v] of Object.entries(obj)) { const cleaned = _dropNull(v); if (cleaned !== undefined) result[k] = cleaned; } return Object.keys(result).length > 0 ? result : undefined; } function _sortKeys(obj) { if (Array.isArray(obj)) return obj.map(_sortKeys); if (obj === null || typeof obj !== 'object') return obj; const sorted = {}; for (const k of Object.keys(obj).sort()) { sorted[k] = _sortKeys(obj[k]); } return sorted; } function _canonical(payload) { const cleaned = _dropNull(payload); return JSON.stringify(_sortKeys(cleaned)); } /** * Verify an OmyPayments webhook signature. * @param {object} payload - Parsed JSON body (may include 'signature' key). * @param {string} secret - Webhook secret from merchant dashboard. * @param {string} signature - Value of payload.signature. * @returns {boolean} */ function verifySignature(payload, secret, signature) { const { signature: _sig, ...rest } = payload; const msg = _canonical(rest); const expected = 'sha256=' + crypto.createHmac('sha256', secret).update(msg, 'utf8').digest('hex'); const a = Buffer.from(expected, 'utf8'); const b = Buffer.from(signature, 'utf8'); if (a.length !== b.length) return false; return crypto.timingSafeEqual(a, b); } ``` **Usage:** ```javascript app.post('/webhook', express.json(), (req, res) => { const { signature } = req.body; if (!verifySignature(req.body, process.env.WEBHOOK_SECRET, signature)) { return res.sendStatus(403); } // safe to process res.sendStatus(200); }); ``` **Language notes:** `JSON.stringify` does **not** sort keys - the explicit recursive `_sortKeys` step is required. `JSON.stringify` does not escape non-ASCII characters by default, which matches the spec. `crypto.timingSafeEqual` requires equal-length buffers - the length check before the call is intentional. *** **PHP** ```php $v) { if ($v === null) { continue; } $result[$k] = _dropNull($v); } if ($isList) { return array_values($result); } if (empty($result)) { return null; } ksort($result, SORT_STRING); return $result; } function _canonical(array $payload): string { $cleaned = _dropNull($payload); return json_encode($cleaned, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_THROW_ON_ERROR); } /** * Verify an OmyPayments webhook signature. * * @param array $payload Parsed JSON body (may include 'signature' key). * @param string $secret Webhook secret from merchant dashboard. * @param string $signature Value of $payload['signature']. * @return bool */ function verifySignature(array $payload, string $secret, string $signature): bool { unset($payload['signature']); $expected = 'sha256=' . hash_hmac('sha256', _canonical($payload), $secret); return hash_equals($expected, $signature); } ``` **Usage:** ```php $rawBody = file_get_contents('php://input'); $payload = json_decode($rawBody, associative: true, flags: JSON_THROW_ON_ERROR); $signature = $payload['signature'] ?? ''; if (!verifySignature($payload, $_ENV['WEBHOOK_SECRET'], $signature)) { http_response_code(403); exit; } // safe to process $invoiceId = $payload['id']; ``` **Language notes:** `ksort` must be applied recursively - the standard `json_encode` does not sort keys. `array_is_list` distinguishes PHP lists (sequential int keys) from associative arrays: lists get `array_values` re-indexing after null removal, associative arrays get `ksort`. `JSON_UNESCAPED_UNICODE` outputs UTF-8 directly; `JSON_UNESCAPED_SLASHES` prevents `/` from being escaped as `\/`. `hash_equals` provides constant-time comparison. *** **Go** ```go package main import ( "bytes" "crypto/hmac" "crypto/sha256" "encoding/hex" "encoding/json" "fmt" "sort" ) func dropNull(v interface{}) interface{} { switch val := v.(type) { case map[string]interface{}: result := make(map[string]interface{}) for k, item := range val { if item == nil { continue } cleaned := dropNull(item) if cleaned != nil { result[k] = cleaned } } if len(result) == 0 { return nil } return result case []interface{}: var result []interface{} for _, item := range val { if item == nil { continue } result = append(result, dropNull(item)) } return result default: return v } } func sortedMarshal(v interface{}) ([]byte, error) { switch val := v.(type) { case map[string]interface{}: keys := make([]string, 0, len(val)) for k := range val { keys = append(keys, k) } sort.Strings(keys) var buf bytes.Buffer buf.WriteByte('{') for i, k := range keys { if i > 0 { buf.WriteByte(',') } keyBytes, _ := json.Marshal(k) buf.Write(keyBytes) buf.WriteByte(':') valBytes, err := sortedMarshal(val[k]) if err != nil { return nil, err } buf.Write(valBytes) } buf.WriteByte('}') return buf.Bytes(), nil case []interface{}: var buf bytes.Buffer buf.WriteByte('[') for i, item := range val { if i > 0 { buf.WriteByte(',') } b, err := sortedMarshal(item) if err != nil { return nil, err } buf.Write(b) } buf.WriteByte(']') return buf.Bytes(), nil default: // scalar: use encoder with HTML escaping disabled var buf bytes.Buffer enc := json.NewEncoder(&buf) enc.SetEscapeHTML(false) if err := enc.Encode(v); err != nil { return nil, err } return bytes.TrimRight(buf.Bytes(), "\n"), nil } } func canonical(payload map[string]interface{}) (string, error) { cleaned := dropNull(payload) if cleaned == nil { return "{}", nil } b, err := sortedMarshal(cleaned) if err != nil { return "", err } return string(b), nil } // VerifySignature verifies an OmyPayments webhook signature. // Pass the parsed payload (may include the "signature" key) and the raw signature string. func VerifySignature(payload map[string]interface{}, secret, signature string) (bool, error) { delete(payload, "signature") msg, err := canonical(payload) if err != nil { return false, err } mac := hmac.New(sha256.New, []byte(secret)) mac.Write([]byte(msg)) expected := "sha256=" + hex.EncodeToString(mac.Sum(nil)) return hmac.Equal([]byte(expected), []byte(signature)), nil } // ParseWebhookBody parses a raw JSON callback body into a map, preserving number types. func ParseWebhookBody(rawBody []byte) (map[string]interface{}, error) { dec := json.NewDecoder(bytes.NewReader(rawBody)) dec.UseNumber() // prevents float64 coercion of integers like "decimals":6 var payload map[string]interface{} if err := dec.Decode(&payload); err != nil { return nil, err } return payload, nil } // Example HTTP handler func webhookHandler(rawBody []byte, secret string) error { payload, err := ParseWebhookBody(rawBody) if err != nil { return fmt.Errorf("invalid JSON: %w", err) } sig, _ := payload["signature"].(string) ok, err := VerifySignature(payload, secret, sig) if err != nil || !ok { return fmt.Errorf("invalid signature") } // safe to process _ = payload["id"] return nil } ``` **Language notes:** * **`json.Decoder.UseNumber()`** -when decoding a JSON body into `map[string]interface{}`, Go maps all JSON numbers to `float64` by default. `UseNumber()` preserves them as `json.Number` (the exact original string), which then serializes back to the exact original representation. Without this, `"decimals":6` would round-trip correctly, but large integers or numbers with specific precision could drift. * **`enc.SetEscapeHTML(false)`** - Go's `json.Encoder` escapes `<`, `>`, `&` to `<`, `>`, `&` by default. This would produce a different canonical string than the spec. Always disable HTML escaping. * **Manual key sorting** - `encoding/json` does not guarantee key order when marshaling `map[string]interface{}`. Always sort keys explicitly before serializing. * **Arrays (`[]interface{}`)** - when `dropNull` encounters a JSON array it removes null elements and recurses into the remaining items; `sortedMarshal` serializes them in their original order (arrays are never re-sorted). Both functions use a `switch` type assertion so slices are handled explicitly rather than falling through to the scalar branch. * **`hmac.Equal`** - constant-time byte comparison. Do not use `==` or `bytes.Equal` to compare signatures. *** #### Recommendations **Idempotency by invoice ID.** OmyPayments does not include replay protection (timestamps, nonces). To guard against a valid callback being replayed, track which invoice IDs you have already processed and ignore duplicates: ```python if already_processed(payload['id']): return HttpResponse(status=200) # acknowledge, but don't act again ``` **Date formats.** Invoice callbacks use `"2025-01-01 00:00:00"` (UTC, no timezone marker); swap callbacks use RFC3339 (`"2025-03-11T14:30:16+00:00"`). Both are opaque strings during canonicalization — no parsing needed for signature verification. # Invoice Statuses ### Invoice Statuses * **new**: Invoice created; awaiting asset selection. (Typically, there is a limited time for asset selection, after which the invoice is canceled.) * **pending**: Asset selected; awaiting payment. (Payment must be made within a set timeframe, otherwise the invoice is canceled.) * **rejected**: Invoice canceled; payment cannot be made. * **finished**: Invoice successfully paid; funds have been credited to the merchant’s account. # Common issues This section addresses some common issues and their solutions. #### 1. API Key Not Working **Problem:** You receive an error message such as `Missing api key` or `Invalid api key`. **Solution:** * Ensure that your API key is correctly included in the `apiKey` header. * Verify that you have copied the API key accurately from your account dashboard at [https://dashboard.omypayments.com/](https://dashboard.omypayments.com/site/login). * Check that the API key has not expired or been revoked. #### 2. Invoice Not Updating **Problem:** The invoice status does not change after its creation. **Solution:** * Confirm that the payment has been made and confirmed on the blockchain. * Verify that the Callback URL is correctly configured and is receiving status updates. * Ensure that your system correctly processes incoming callbacks. #### 3. Callback Not Received **Problem:** Your server is not receiving webhook callbacks. **Solution:** * Check that your server endpoint is publicly accessible and returns a `200` status code. * Ensure that no firewall or network restrictions block incoming requests. * Verify that the Callback URL is correctly registered in your merchant settings. # Overview Omypayments API is designed to work seamlessly with your existing tools—even if you don’t have native no‑code widgets. Although we do not provide built‑in no‑code components, you can quickly integrate our API with popular no‑code platforms (like Zapier, Integromat, or similar) to set up automated payment workflows. **What You Can Achieve:** * **Rapid Deployment:** Set up payment processing in minutes using your favorite no‑code platform. * **User-Friendly Automation:** Leverage visual editors and pre‑built integrations from platforms such as Zapier. * **Dynamic Payment Links:** Generate payment links with hidden parameters (e.g., invoice amounts) that direct customers to secure payment pages. * **Seamless API Integration:** Easily connect our API with your no‑code tools to automate tasks like invoice creation and payment confirmations. **Key Benefits:** * No development resources required. * Lower integration costs. * Fast time‑to‑market with automated workflows. # Getting Started with No‑Code Integration This guide walks you through the basics of integrating Omypayments using no‑code platforms. **Step 1: Sign Up and Retrieve Your API Key**\ Log in to your merchant dashboard at [https://dashboard.omypayments.com/](https://dashboard.omypayments.com/site/login) to obtain your API key. This key authenticates your API requests. **Step 2: Choose Your No‑Code Platform**\ Since Omypayments doesn’t offer native no‑code widgets, select a platform like Zapier or Integromat that can handle HTTP requests and integrate with REST APIs. **Step 3: Configure Your Integration Flow**\ Using the chosen platform’s visual editor, set up a workflow that: * Triggers an action (e.g., when a new order is placed). * Sends a request to create an invoice via Omypayments API. * Optionally, retrieves and displays the payment link in your application. **Step 4: Connect Your API**\ Insert your API key into the integration’s settings. Test the connection to ensure the API responds correctly. **Step 5: Deploy and Monitor**\ Once configured, activate your workflow. Monitor its performance and adjust triggers or actions as needed. # How to Create Payment Links Payment links allow you to generate a dedicated payment page without writing any code. Even though Omypayments does not offer its own no‑code widget, you can easily set up payment links using third‑party no‑code tools. **How It Works:** * **Dynamic Invoice Generation:**\ A no‑code workflow (via Zapier, for example) sends a request to the Omypayments API to create an invoice. The API generates a payment link with hidden parameters (like the invoice amount). * **User Interface:**\ The generated payment link directs customers to a payment page displaying a prominent “Pay” button. Hidden fields (containing invoice details) ensure the correct amount is processed. * **Behind the Scenes:**\ When the customer clicks “Pay,” the hidden parameters are submitted, and the system validates the data before processing the payment. **Example Workflow:** 1. **Trigger:**\ A customer clicks a “Pay” button on your website. 2. **Invoice Creation:**\ A Zapier workflow creates an invoice via the Omypayments API. 3. **Link Generation:**\ The API returns a payment link with hidden parameters (e.g., amount). 4. **Payment Page:**\ The customer is directed to the payment page and completes the payment. 5. **Confirmation:**\ The system updates the invoice status and sends a callback to your endpoint. # Advanced Use Cases and Best Practices for No‑Code Integration Once you’ve set up basic no‑code integration, consider these advanced scenarios to further automate your payment workflows: **1. Automated Order Processing:** * Integrate Omypayments with your e‑commerce platform using Zapier. * Automatically generate invoices when an order is placed and send notifications to your team. **2. Subscription and Recurring Billing:** * Use no‑code tools to schedule recurring invoice generation for subscription services. * Combine workflows with email marketing tools for renewal reminders. **3. Customized Payment Experiences:** * Tailor your payment page by configuring hidden fields (such as discount codes or loyalty points) within your no‑code workflow. * Use conditional logic available in platforms like Integromat to adjust payment parameters dynamically. **Best Practices:** * **Thorough Testing:**\ Test every element of your workflow (invoice creation, payment links, callbacks) to ensure a smooth experience. * **Secure Your Integrations:**\ Always protect your API key and ensure your callback endpoints are publicly accessible and return a `200` status code. * **Monitor and Optimize:**\ Regularly review your integration performance and user feedback to refine your workflows. # Terms of Use Please read these Terms of Use ('Terms') carefully before using any of the services provided by the OmyPayments website (https\://omypayments.com) (the 'Website') and Application Programming Interface If you do not agree to these Terms, you may not visit or use the Website or any Services provided on the Website. All information and Services provided on the Website are provided strictly «as is» without warranty of any kind. Please leave the Website and do not create an account if you do not agree to the terms and conditions set out below. Otherwise, you assume all risk and responsibility for the storage and trading of virtual currency, even though we have warned you not to do so. By signing up through the Website, you agree that you have read, understood, and accept all of the Terms. If you do not agree or fail to adhere to the Terms or any other rules of any of the Services, you are not entitled to use the Services. If you are a U.S. citizen or resident, please leave the Website. OmyPayments does not serve U.S. citizens or residents. Accordingly, by using the Services, you also confirm that you are not a citizen or resident of the United States or a citizen or resident of the list of prohibited countries set forth on our website's AML policy. #### 1. Terms and definitions 1.1 **Account** – an account opened by you on the Site to access the Services on the Site. 1.2 **AML Policy** – rules of behaviour aimed at preventing money laundering and terrorist financing developed by OmyPayments in accordance with the Governing Laws, which form an integral part of the Terms and are available at [https://omypayments.com](https://omypayments.com/). 1.3 **Governing Law** means the laws, international regulations, and agreements applicable under these Terms to all relationships between you and the Platform. 1.4 **OmyPayments** (also referred to as the 'Platform') - an online platform and payment infrastructure operated by OmyPayments that offers cryptocurrency transactions, mass payouts, cryptocurrency exchanges via third-party providers, and other services as set out in Section 3 of these Terms. 1.5 **Deposit** – a transaction consisting of the transfer of virtual currency units from external wallets to your Account. 1.6 **Services** – any services provided on the OmyPayments Platform as set out in Section 3 of the Terms. 1.7 **Exchange** – an exchange transaction of virtual currency to another cryptocurrency or vice versa, or virtual currency to another virtual currency, carried out through the Account. 1.8 **Exchange Rate** – the ratio of the value of assets in trading pairs based on demand, supply, value, utility of assets, and other economic variables. 1.9 **Commission** – commission or other charges levied by OmyPayments for the use of the Services. 1.10 **Privacy Policy** – the rules for the collection, storage, and use of personal data developed by OmyPayments in accordance with regulatory laws, which form an integral part of the Terms and are available at 1.11 **Withdrawal** – a transaction consisting of transferring Virtual Currency(cryptocurrency) units from your Account to external wallets. 1.12 **User** (also referred to as 'You', 'Your') - an individual (natural person) or a legal entity established in the appropriate legal form, who has opened an account on the Website, who can enter into a legally binding contract and use the Website, and who is not prohibited from doing so and using the Services under the Regulatory Laws or any other laws that may apply. 1.13 **Virtual Currency** is a decentralised peer-to-peer digital asset that has no central issuer and is not legal tender, securities, electronic money or money under the Governing Law. 1.14 **Virtual Currency Merchant** – a third-party provider of goods and/or services that supports payments in virtual currencies through the User's Account on the Platform. 1.15 **Website** – the internet site maintained and owned by OmyPayments at . #### 2. Terms of use status and acceptance 2.1 These Terms constitute a legally binding agreement between you and OmyPayments. 2.2 These Terms apply to all Services, information, text and other products offered by OmyPayments on the Website. 2.3 By accessing the Website, opening an Account on the Website or ticking the 'I agree to the Terms of Use and Privacy Policy' box, you agree to these Terms and confirm that you have read, understood and accepted all provisions of these Terms, as well as the provisions of our Privacy Policy, AML Policy and other legally binding documents publicly available on the Website. 2.4 You may not use the Website or create an Account unless you have read, understood and accepted all provisions of these Terms. 2.5 OmyPayments may change, remove, or add context to the Terms and reserves the right to do so in its sole discretion. All new and/or revised provisions of the Terms are effective immediately and apply to your use of the Website, Account and Services from that date. Please check these Terms regularly to ensure that you are aware of all current provisions of these Terms. 2.6 OmyPayments may notify you of material changes to these Terms. This may be done by posting a notice on the Website or by sending you an email (if appropriate). 2.7 You can review the most current version of the Terms using the Terms of Use link. If you continue to use the Website after OmyPayments makes changes to the Terms, you expressly confirm your acceptance of the new and/or revised Terms. 2.8 These Terms, including our Privacy Policy and the AML Policy, all notices, notifications, policies, warnings and disclaimers, constitute the entire agreement between you and OmyPayments. 2.9 Platform users assume full responsibility for all risks associated with the use of cryptocurrencies. These may include: * Theft or loss due to negligence; * Lack of collateralisation of cryptocurrency; * Cybersecurity risks; * Virtual currency fraud; * Lack of consumer protection; * High volatility; * Currency regulation; * Taxation of virtual currencies; #### 3. Services 3.1 The OmyPayments provides the following services on the Website (collectively – «Services», and separately – the «Service»): * Exchange of Virtual Currency units for units of another Virtual Currency or fiat money via third-party centralized and decentralized services; * Virtual Currency temporary custody services; * Depositing and withdrawing units of Virtual Currency on the Platform; 3.2 By providing a Service of exchanging Virtual Currency units for units of another Virtual Currency or fiat money, OmyPayments uses the then-prevailing spot market exchange or decentralized exchanges, or third-party off-ramp providers' platform rate for the given trading pair (e.g., BTC/USD). You acknowledge and agree that the prices displayed on our Platform are derived from multiple market data sources and may not directly match prices quoted on other exchanges, conversion services, decentralized exchanges, or market data providers. 3.3 By providing a wallet/custody Service, OmyPayments provides you with a digitally secured wallet for Virtual Currencies, aimed at exchanging, storing, and withdrawing units of Virtual Currencies, and securely stores your private keys for these purposes using our own and third-party infrastructure for these purposes. 3.4 To access Services, laid down in Sections 3.2 and 3.3 of the Terms, you must deposit units of Virtual Currencies on the Platform. 3.5 Deposits and withdrawals are conducted in accordance with Section 9 of the Terms. 3.6 OmyPayments may, at its sole discretion, disable access to the Website, the Account, specific Services, or all Services without providing any reason. 3.7 OmyPayments only offers Services for Virtual Currencies supported by the Platform. Please check the Website regularly to confirm which Virtual Currencies are supported. You should not attempt to deposit Virtual Currencies that the Platform does not support. 3.8 The provision of Services might be delayed due to circumstances, including but not limited to technical difficulties, reasonable doubts about the nature or source of funds deposited on the Platform, or the need to conduct AML/KYC checks as outlined in the AML Policy. 3.9 OmyPayments may also provide you with an aggregated nominal value of all your assets in EUR, BTC or any other currency or Virtual Currency based on their current exchange rate. 3.10 Privacy transfers are facilitated via the Hinkal protocol, ensuring enhanced privacy for transactions. 3.11 Mass payouts in several chains #### 4. User's eligibility 4.1 To access the Services, you must open an Account on the Website by undergoing a registration procedure on the Website. 4.2 The Services and the use of the Website are available to individuals or legal entities who: * are at least 18 years of age (for individuals); * have the capacity to enter into a legally binding contract and use the Website, and are not prohibited to do so and use the Services by the Regulatory Law or any other laws that may apply; * are residing or incorporated in countries and territories we support. 4.3 You can only have one Account on the Website. You should not create more than one Account on the Website unless expressly permitted by OmyPayments. 4.4 You cannot create an Account on the Website if your Account has previously been suspended by OmyPayments. #### 5. Personal account 5.1 When opening an Account on the Website, you warrant that all information submitted by you is accurate, valid, up-to-date, and complete. 5.2 You shall not use your Account for illegal purposes and activities, which may include but are not limited to money laundering, terrorism financing, human, drug, weapon, and sex trafficking, or tax evasion. 5.3 You must not create an Account on behalf of another individual or entity unless you are legally authorized to do so. 5.4 You are solely responsible for keeping your Account secure. Do not share your login, password, or any other access details with others. 5.5 You must notify OmyPayments immediately upon becoming aware of any breach of security or unauthorized use of your Account. Please contact us at immediately in this case! 5.6 OmyPayments reserves its right to suspend your Account without providing notice or reason in case of any violation of these Terms. #### 6. Registration Requirements 6.1 To receive access to the Services provided on the Website, you will have to provide certain information and documents and undergo a verification procedure. For more information, please read the AML Policy. 6.2 The OmyPayments may at any time request you to provide additional documents and information, and/or updated documents and/or information and documents submitted before, and reserves the right to do so at its sole discretion. Failure to abide by these requirements may result in temporary or permanent cessation of Services provision and/or Account suspension and/or funds freezing. 6.3 You are solely responsible for the accuracy, validity, and correctness of all information and documentation you submit to OmyPayments. Should there be any error, mistake, update, or change in information or documents you have submitted previously, you are obliged to notify OmyPayments immediately. 6.4 Information and documents submitted by you to OmyPayments are processed according to the provisions of our Privacy Policy. #### 7. User Conduct 7.1 While visiting, accessing, and using the Website and Services, you agree to: * not violate or assist any third party in violating these Terms and/or any Regulatory Law, which may include but is not limited to international laws, national laws, statutes, regulations, etc.. * not provide false, inaccurate, incomplete, and misleading information to the OmyPayments; * not violate intellectual property rights (trademark, copyright, patent, and other intellectual property rights) of the OmyPayments specified in paragraph 13 of these Terms; * not use the Website in any way that can damage, disable or overburden the Website, which may include but is not limited to uploading or in any other way, while using the Website, sending viruses, Trojan horses, spyware, adware or any other malicious code; performing DDoS attacks, interfering with or disrupting any network, equipment, or server connected to or used to provide services on the Website; * not attempt to gain unauthorized access to the Website, other Users' Accounts, computer systems or networks connected to the Website, or to extract data from the Website; * not share your Account and/or password with third parties or use any other person's Account and/or password; * not impersonate or misrepresent your affiliation with another User, person, or entity, nor make other fraudulent, false, deceptive, or misleading representations; * not violate any laws that apply in your jurisdiction concerning the use of Virtual Currency; * not violate these Terms and the Regulatory Law in any other way. #### 8. Account closing & suspension 8.1 You can close your Account at any time at your sole discretion. 8.2 Before closing your Account, all your assets have to be withdrawn to external wallets. 8.3 OmyPayments reserves the right to suspend your Account in the event: * we reasonably believe your Account has been compromised, as well as for any other security reasons; * we reasonably believe your Account is being used by a person with no right and/or authorization to do so; * you fail to comply with these Terms, the AML Policy, and the Privacy Policy, as well as with any other document that construes a part of these Terms; * you have provided us with any false, incomplete, misleading, or inaccurate information; * you, your Account, and your behavior pose regulatory risks to the OmyPayments; * we reasonably suspect you of fraud, violating the Regulatory Law; * other reasons that constitute a violation of these Terms and the Regulatory Law. 8.4 The OmyPayments may, but is not obliged to, notify you about the reasons for your Account suspension. Assets from your Account may be blocked without the right to withdraw. 8.5 In the event of Account closing or suspension, you will still be liable for all applicable Fees. 8.6 OmyPayments is not liable for any losses suffered due to your Account closure or suspension. #### 9. Deposits and withdrawals 9.1 Before using the Services, you have to deposit units of Virtual Currency into your Account by following the Deposit instructions on your Account page. Please carefully read the Deposit instructions. 9.2 You can withdraw units of Virtual Currency at any time at your sole discretion, subject to Account transaction limits and temporary or permanent restrictions imposed in the course of an internal investigation or by law (e.g., court orders). 9.3 You can withdraw your units of Virtual Currency in any amount, provided there are enough Virtual Currency units to cover the applicable Fees. 9.4 Each Withdrawal of Virtual Currency is subject to a mining fee charged by the respective blockchain network. When sending your transaction to the blockchain, we will try to keep the balance between reasonable fees and speed of processing, however, we reserve the right to determine the exact amount of mining fee to be set in our sole discretion. You can check the exact amount of mining fee charged for the specific transaction by checking the respective blockchain explorer (e.g. [https://www.blockchain.com](https://www.blockchain.com/) for BTC and BCH, [https://etherscan.io](https://etherscan.io/) for ETH, etc.). 9.5 The OmyPayments shall not be liable for the transfer of your units of Virtual Currency to other wallets. You are solely liable for the accuracy of information required for carrying out a Withdrawal (i.e., addresses, tags, and any other required credentials). OmyPayments strongly advises you to always double-check the accuracy of information provided for Withdrawal purposes. 9.6 You shall always keep in mind that blockchain transactions are irreversible, and therefore, once the transaction has been sent to the blockchain network upon your request (in case of Withdrawals), we cannot reverse it at all. #### 10. Fees 10.1 The Platform is operated on an automatic Fee-charging basis for the Services, and OmyPayments does not issue any invoices. The applicable Fees for any transaction will be displayed to you before or after executing a given transaction, depending on the type of services you use. 10.2 The OmyPayments may change the Fee structure at any time (including adding new fees for new Services) and reserves the right to do so in its sole discretion. The OmyPayments will notify you about any changes in the Fee structure. This can be done by posting a notification on the Website or sending you an email (if appropriate). 10.3 Fees are paid in a Virtual Currency that corresponds to the respective Service. 10.4 Fees shall be paid at the time of the completion of each transaction. #### 11. Settlements, cancellations, and refunds 11.1 When depositing, withdrawing, or exchanging units of Virtual Currencies for another Virtual Currency/fiat money, respective assets shall be debited and credited onto your Account. 11.2 Once your order to exchange Virtual Currency has been completed, it cannot be canceled or reversed. Exchanges are final, and there are no refunds for them. 11.3 The order to exchange Virtual Currency can be canceled by OmyPayments in the event of a technical fault of the Platform. #### 12. Content 12.1 The OmyPayments may produce and display content (the «Content») on the Website, which includes but is not limited to information, texts, images, video, and audio files. 12.2 The Content does not constitute any form of investment advice, financial advice, trading advice, or any other sort of advice unless specifically mentioned otherwise and should not be construed as such. The OmyPayments shall not hold liability for any actions that arise from its Content. #### 13. Intellectual property 13.1 All components, Content of the Website, and the Website as a whole belong to OmyPayments and are protected, including, but not limited to, copyright, trademarks, and trade secrets. All rights reserved. 13.2 You must not reproduce, reprint, publish, modify, distribute, display, transmit, license, transfer, or otherwise exploit Content or technology from the Website without OmyPayments's prior written consent. 13.3 Violation of any of the intellectual property rights of OmyPayments is strictly prohibited. #### 14. Links to third-party websites 14.1 The Website may contain links to third-party websites or services that are not owned or controlled by OmyPayments. 14.2 The OmyPayments has no control over and assumes no responsibility for the content, privacy policies, or practices of any third-party websites or services. The OmyPayments shall not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any such content, goods, or services available on or through any such websites or services. 14.3 For more information, please read these companies' public policies. #### 15. Confidentiality and privacy policy 15.1 Personal information that you provide to the OmyPayments, including information provided in accordance with our AML Policy and any information about your use of the Website that the OmyPayments obtains, will be subject to our Privacy Policy. 15.2 The OmyPayments may be obliged to disclose your personal information to law enforcement authorities, data protection authorities, financial regulators, financial service providers, governmental authorities and officials, and other authorized persons, as set forth in the Privacy Policy. 15.3 In the event the OmyPayments suspects you of violating the AML Policy, we shall report such behavior and disclose relevant personal information to relevant authorities in accordance with the Regulatory Law. #### 16. Disclaimers and limitations of liability 16.1 For non-performance or improper performance of their obligations under these Terms, OmyPayments and you shall be liable in accordance with these Terms and the Regulatory Law. 16.2 The Website, Content, and Services are provided without any guarantees, conditions, or warranties as to their accuracy, quality, and fitness for a particular purpose or need. OmyPayments does not guarantee that the Website and Services are error-free, reliable, or will operate without interruption. 16.3 The Website is provided to you on an «AS-IS» basis. 16.4 The OmyPayments does not guarantee that any exchange requests will be accepted, executed, or recorded. 16.5 The OmyPayments shall not be liable for the use or inability to use the Website and Services. 16.6 In no event shall the OmyPayments, its officers, directors, employees, agents, third-party service providers be liable to you or any other person or entity for any direct, indirect, incidental, special, punitive, or consequential damages whatsoever, including any that may result from (i) the accuracy, completeness, or content of the Website, (ii) the accuracy, completeness, or content of any websites linked (through hyperlinks, banner advertising or otherwise) to the Website, (iii) the Services found at the Website or any websites linked (through hyperlinks, banner advertising or otherwise) to this Website, (iv) personal injury or property damage of any nature whatsoever, (v) third-party conduct of any nature whatsoever, (vi) any unauthorized access to or use of OmyPayments's servers and/or any and all content, personal information, blockchain information or other information and data stored therein, (vii) any interruption or cessation of Services to or from the Website or any websites linked (through hyperlinks, banner advertising or otherwise) to this site, (viii) any viruses, worms, bugs, trojan horses, or the like, which may be transmitted to or from this site or any websites linked (through hyperlinks, banner advertising or otherwise) to this Website, (ix) any loss or damage of any kind incurred as a result of your use of the Website or the Services found at the Website, whether based on warranty, contract, tort, or any other legal or equitable theory, and whether or not the OmyPayments is advised of the possibility of such damages, (x) losing access and/or unauthorized access to your Account, (xi) any errors or malfunctions caused by or otherwise related to any wallets used to deposit and withdraw Virtual Currencies, (xii) malfunctions, breakdowns and abandonment of blockchain protocols, (xiii) changes in regulatory approaches or legal actions taken regarding the blockchain technology and Virtual Currency, (xiv) taxation and/or changes in tax system regarding Virtual Currencies, (xv) advancements in cryptography, any technical advancements that may present risks to blockchain protocols, (xvi) unfavorable fluctuations of Virtual Currencies, (xvii) errors in the provision of Services; (xviii) other risks associated with purchasing, holding, and Virtual Currencies, and using the Website and Services. 16.7 The OmyPayments shall not be liable for any events that may include, but are not limited to, civil, criminal, and administrative actions that may arise from your using blockchain and Virtual Currency if such use is forbidden or otherwise limited in your country. 16.8 The OmyPayments, its officers, directors, employees, and agents do not provide investment advice, financial advice, trading advice, legal advice, or any other sort of advice. 16.9 To the extent permitted by Regulatory Law, you agree to defend, indemnify, and hold harmless the OmyPayments from and against any and all claims, damages, obligations, losses, liabilities, costs or debt, and expenses arising from: (i) your use of and access to the Website and Services; (ii) your violation of any term of these Terms; or, (iii) your violation of the Regulatory Law, including any law, rule, or regulation, or the rights of any third party. 16.10 In case of any circumstances of insuperable force (i.e. events of extraordinary or insuperable nature) that have occurred and remain in effect beyond your and the OmyPayments's (the «Parties'») control and that a Party could neither foresee nor prevent for objective reasons, if these circumstances prevent a Party from proper fulfilment of its obligations hereunder, the term for fulfilment of such obligations hereunder shall be extended for the period of the effect of such circumstances of insuperable force. The circumstances of insuperable force shall include wars and other military operations, earthquakes, floods, and other natural disasters, adoption of laws and regulations by state and local authorities, failure of power supply or communication system, or other similar circumstances that prevent the Parties from the proper fulfilment of their obligations hereunder. #### 17. Announcements 17.1 The OmyPayments may from time to time post official announcements, news, notices, etc. (the «Announcements») on the Website. In no event shall the OmyPayments be liable for any losses arising from you neglecting or ignoring the Announcements. 17.2 By agreeing to the terms of this Agreement, the user consents to receive email notifications. #### 18. Regulatory law and dispute resolution 18.1 Each party is obliged to maintain the confidentiality of all information related to the subject matter of the dispute disclosed during or for the purposes of dispute resolution, except in cases where a regulatory or governmental authority, court, or tribunal compels this Party to disclose this information. 18.2 A Party must not begin legal proceedings in connection with a dispute arising out of or in connection with this Agreement unless an amicable solution has been attempted between the Parties. 18.3 Disputes and disagreements that may arise in the performance of obligations under this Agreement will be resolved by the Parties by negotiation. If the dispute is not resolved within 1 (one) month after an attempt at an amicable solution between the Parties, the Parties will resolve the dispute through the mediation process. #### 19. Force Majeure 19.1 We will not be liable for delays, failure in performance or interruption of service which results directly or indirectly from any cause or condition beyond our reasonable control, including, but not limited to, any delay or failure due to any act of God, act of civil or military authorities, act of terrorists, civil disturbance, war, strike or other labour dispute, fire, interruption in telecommunications or internet services or network provider services, failure of equipment or software, other catastrophe or any other occurrence which is beyond our reasonable control and will not affect the validity and enforceability of any remaining provisions. #### 20. Final Provisions 20.1 These Terms shall remain in force until terminated either by you or OmyPayments. OmyPayments may terminate these Terms at any time at its discretion without explaining the reasons for this decision. 20.2 If any questions have not been regulated by these Terms, they shall be regulated under the Regulatory Law. 20.3 These Terms are a legally binding agreement and together with their other integral parts constitute an entire agreement between you and OmyPayments. 20.4 In the event the Website is available in multiple languages, the English version of the Terms shall prevail. 20.5 All provisions of these Terms applicable to the Website shall apply to other means of providing Services, including the App, unless specifically stated otherwise. 20.6 Should you have any comments, questions, or complaints, please contact us at . # Privacy Policy ### Introduction This Privacy Policy (this “Policy”) explains how OmyPayments website (“OmyPayments”, “we”, “us”, “our”) collects, uses, shares and protects the personal information you provide to us when you use the OmyPayments.com website (the “Site”) or our products. This Statement governs the rules for processing personal information of our customers, their partners, representatives and all other visitors to the Site. OmyPayments is committed to protecting your privacy. We take all necessary legal, technical and organizational measures to ensure the confidentiality, integrity and availability of your Personal Information. By “Personal Information” or “Personal Data” we mean any data by which you can be identified or which can help identify you. The Personal Information Protection and Electronic Documents Act (“PIPEDA”) applies to OmyPayments' processing of Personal Information. #### Our contact details All references to “OmyPayments”, “us”, “we” or “our” refer to OmyPayments website.\ If you have any questions regarding data protection, please contact us at: #### What type of personal information we collect The types of Personal Information we may collect include: * Contact details (email, telephone number or messenger ID) * Details of your identity document * Residence address * Financial information * Employment details * History of your logs and activity on the Website * IP address, browser and operating system information, device fingerprint * Other information required in accordance with the AML policy and/or Terms of Use Most information we collect is provided by you directly. We could also receive some information from publicly available sources (for example, on sanctions) or from our contractors. We make use of screening lists provided by data vendors, ID verification, anti-fraud and transaction monitoring services. Please note that we will not be able to provide our services to you if you refuse to provide us information according to our KYC/AML requirements communicated to you once you decide to apply for any of our services that require verification of identity and ongoing monitoring of activity. Please keep in mind that in some cases we may require additional details and documents for KYC and AML/CTF purposes. Please note that processing of your Personal Data may include automated decision-making including profiling. We may apply automated decision-making including profiling for onboarding, maintaining the account with us and fraud prevention purposes. #### How we get the information and why we have it We process our clients' data for the following purposes: * To provide our services to you, as individual, or a corporate client you represent * To contact you or reply to your requests * To comply with our legal obligations (e.g. KYC/AML requirements) * To provide assistance in case of criminal investigation and regulatory action * To protect your assets from unauthorized access * To prevent any fraud and scam activity * To provide you information on our products, news and updates * To resolve disputes and protect your interests or interests of other users In accordance with international law, we rely on: * Your consent. You are able to withdraw your consent at any time by contacting us at * We have a contractual obligation * We have a legal obligation to comply with AML/CTF requirements under the applicable laws and regulations, keep records for tax purposes * We have a legitimate interest in providing the necessary updates regarding our services, prevent any fraudulent activity proactively and retrospectively, and contacting employees of our clients and business partners #### Personal information collected automatically We may collect personal information automatically when you use our Services, as described below. * **Cookies.** Cookies are small text files placed in device browsers that store preferences and facilitate and enhance your experience. * **Pixel Tags/Web Beacons.** A pixel tag (also known as web beacon) is a piece of code embedded in our Services that collects information about engagement on our Services. #### Who we share your personal information with We may share this information with: * Our affiliates, agents and representatives * Our contractors providing software for identity verification and anti-fraud purposes * Our contractors providing us information from publicly accessible sources (for instance on sanctions) * Our financial service providers through which we facilitate fiat currency transactions to/from our services * Law enforcement or regulatory agencies if required or permitted by law #### Personal data retention We will ensure that any information we need for any purpose shall not be kept for longer than it is necessary. We retain your personal data just to comply with our legal obligations, resolve disputes, and protect your and our legitimate interests. We will retain your personal data for a maximum of seven (7) years after the termination of the legal relationship with us. You can always request the deletion of personal data. But please be aware that in some cases we are required to retain your information to comply with legal requirements. #### Your rights Under data protection law, you have rights including: * Your right of access – You have the right to ask us for copies of your personal information. * Your right to rectification – You have the right to ask us to rectify information you think is inaccurate. You also have the right to ask us to complete information you think is incomplete. * Your right to erasure – You have the right to ask us to erase your personal information. * Your right to restriction of processing – You have the right to ask us to restrict the processing of your information. * Your right to object to processing – You have the right to object to the processing of your personal data. * Your right to data portability – You have the right to ask that we transfer the information you gave us to another organisation, or to you. Please note that in some cases we will not be able to fulfill your request due to our legal obligations or overriding legitimate interest. In such cases we will explain you the reasons why your request cannot be fulfilled and how you can complain. #### Security OmyPayments has implemented security measures to comply with acknowledged international security standards. Our platform also uses SSL or TLS encryption for security reasons and for the protection of confidential content transmission when you send us requests. #### Policy changes OmyPayments may introduce amendments to the current Policy at any time. We may notify you on our Website or via e-mail. # AML Policy OmyPayments is committed to maintaining effective crime prevention and detection measures to assist law enforcement agencies in combating financial crime. The site has adopted a strict set of policies #### Background information Money laundering is a process, i.e. any action or attempt to commit an action in which money and property (assets) obtained as a result of criminal activity are disguised as coming from a legitimate source. In fact, money laundering is a process in which «dirty money» obtained as a result of criminal activity turns into «clean money», the criminal origin of which is difficult to trace. There are three recognized stages in the process of money laundering. **There are three stages in the process of money laundering:** * Placement involves the placement of proceeds from crime in the financial system. * Distribution involves the transformation of proceeds of crime into another form and the creation of complex layers of financial transactions to complicate the control trail and hide the source and ownership of the proceeds. tools. * Integration involves the return of laundered income to the economy. create an idea of legitimacy. Money laundering starts with the proceeds of crime from the predicate offence. The predicate offences include tax evasion, drug trafficking, bribery, fraud, forgery, murder, robbery, counterfeiting, securities manipulation and copyright infringement, among others. A money laundering offence may include property or proceeds derived from illegal activities. Terrorist financing is when you knowingly collect or provide property, such as money, directly or indirectly to terrorists. The main purpose of terrorist activities is to intimidate the public or to get the government to do something. Terrorists need financial support to carry out terrorist activities and achieve their goals. Many of the techniques used for money laundering are also used in terrorist financing, including but not limited to concealing the channelling of funds and the use of third parties. They need to disguise their money so that it comes from a different source and convert it into a form that cannot be easily traced so that it can be utilised. #### 1. Main objectives Clients\&aops; identities are satisfactorily verified in accordance with the firm's risk based approach before Website does business with them. Website knows its clients and understands their reasons for doing business with us both at the client acceptance stage and throughout the business relationship. Our staff are trained and made aware of both their personal legal obligations and the legal obligations of Website. Our staff is trained to be vigilant for activities where there are reasonable grounds for suspicion that money laundering could be taking place and to make the reports to the Compliance Officer. Sufficient records are kept for the required period. We establish, maintain and implement appropriate procedures to achieve these objectives. #### 2. General principles **Anti-money laundering policy** OmyPayments has implemented policies, procedures and controls designed to prevent criminals from using Website to launder the proceeds of crime. These policies and procedures are tailored to the risk posed to individual customers. **Customer Due Diligence ('CDD')** OmyPayments has established customer due diligence procedures to identify the users of its services and, in respect of higher risk customers, the primary beneficial owners and origin of funds. These procedures include knowledge of the nature of our customers' business and vigilance for anomalous transactions. **In general, the CDD policy has been adopted by Website to successfully fulfil the following objectives:** > identification and verification of the applicant for business; > > identification and verification of the beneficial owner, where applicable; > > identification and verification when the applicant for business does not act as principal; > > obtaining information on the purpose and intended nature of the business relationship; > > conducting ongoing monitoring of the business relationship; > > establishing the source of wealth and source of funds; > > setting up of a customer acceptance policy and ensuring that the applicant for business meets the requirements set out in such policy; > > Website is strictly prohibited from keeping anonymous accounts or accounts in fictitious names. **Suspicious transactions** Unexplained or anomalous transactions or activities suspected to be related to criminal activity should be reported immediately in writing to the Compliance Officer, who will determine whether the suspicion should be reported to Law Enforcement. **Training** All personnel must be informed of their individual and collective responsibilities and Website's anti-money laundering policies. Personnel are provided with training to enable them to understand the vulnerabilities of Website's business and to recognize and report suspicious activities. **Record-keeping** The website keeps records of who has been trained and the time and form of the training sessions. We keep all records confirming the identity of our customers for at least 7 years after the end of the business relationship. We also keep records of any internal reports of suspicion made to the Compliance Officer. #### 3. Our responsibilities **All money service businesses are required by International Law to:** > Develop a programme to ensure compliance with reporting, record keeping and customer identification requirements; > > Comply with customer identification rules and maintain specific records for specific transactions; > > Report suspicious transactions, large cash transactions and information related to terrorist property. #### 4. Risk based approach **What is risk?** **Risk can be defined as the likelihood of an event and its consequences. In simple terms, risk can be seen as a combination of the chance that something may happen and the degree of damage or loss that may result from such an occurrence. In the context of money laundering/terrorist financing (ML/TF), risk means:** > At the national level: ML/TF threats and vulnerabilities that jeopardise the integrity of the financial system. > > At the Company level: threats and vulnerabilities that put the Company at risk of being used to facilitate ML/TF **All clients default to low risk, UNLESS risk factors are present such as; Automatic high- risk characteristics – if any of the flags below are present the client is high risk.** > Politically exposed person > > A client where a suspicious transaction, terrorist financing report has been filed > > A client who is an identified terrorist > > A client for whom we are unable to obtain beneficial ownership information > > A client from high-risk country **Client characteristics, product, service, delivery channel:** > Politically exposed person, head of international organization and close associates; > > Unknown source of funds; > > Large transaction (ETF) orders from/to high-risk foreign jurisdictions; > > Third party involvement without reasonable justification; > > Occupation – High-risk occupations (e.g., cash intensive businesses, offshore business, business in high-risk countries, online gambling); > > Client's business structure or transactions seems unusually complex; > > Non face-to-face client identification without justifiable reason. **Geography:** > Client resides outside local or normal client area; > > Client resides in known crime area; > > Client has offshore business activities, client connections to high-risk countries. **Other suspicious transaction indicators:** > Volume/timing/complexity of transactions inconsistent with the client's personal/business activity and/or purpose of the services/account; > > Value of deposits/transfers inconsistent with occupation or source of funds; > > Presence of any suspicious transaction indicators outlined in Part A “Background information” section. #### 5. Indicators of suspicious transactions or potential high-risk clients The following are examples of some general and industry-specific indicators that may give you reasonable grounds to suspect that a transaction involves money laundering or terrorist financing. The presence of one or more of these factors does not mean that the transaction is suspicious and should be reported to a regulator, but it does indicate that a more in-depth examination is required. **General indicators.** **The following are a few examples of general indicators that might lead us to suspect that a transaction is related to a money laundering or terrorist activity financing offence. It will not be just one of these factors alone, but a combination of several factors in conjunction with what is normal and reasonable in the circumstances of the transaction or attempted transaction.** > Client admits to or makes statements about involvement in criminal activities; > > Client refuses or tries to avoid providing information required, or provides information that is misleading, vague, or difficult to verify; > > Client produces seemingly false documentation that appears to be counterfeited, altered or inaccurate; > > Client appears to have accounts with several financial institutions in one area for no apparent reason; > > Client repeatedly uses an address but frequently changes the name involved; > > Client shows uncommon curiosity about internal controls and systems; > > Client presents confusing details about the transaction; > > Client makes inquiries that would indicate a desire to avoid reporting; > > Client is involved in unusual activity for that individual or business; > > Client presents confusing details about the transaction or knows few details about its purpose; > > Client seems very familiar with money laundering or terrorist activity financing issues; > > Client refuses to produce personal identification documents; > > Client frequently travels to a high-risk country. **Industry specific examples** > Client requests a transaction at a foreign exchange rate that exceeds the posted rate. > > Client wants to pay transaction fees that exceed the posted fees. > > Client exchanges currency and requests the largest possible denomination bills in a foreign currency. > > Client knows little about address and contact details for payee, is reluctant to disclose this information, or requests a bearer instrument. > > Client wants a cheque issued in the same currency to replace the one being cashed. > > Client wants cash converted to a cheque and you are not normally involved in issuing cheques. > > Client wants to exchange cash for numerous postal money orders in small amounts for numerous other parties. > > Client enters into transactions with counter parties in locations that are unusual for the client. > > Client instructs that funds are to be picked up by a third party on behalf of the payee. > > Client makes large purchases of traveler's cheques not consistent with known travel plans. > > Client makes purchases of money orders in large volumes. #### 6. Data request To mitigate the risks associated with money laundering and terrorist financing, we strictly do not accept or send payments to third parties (unidentified). Each customer may only send and receive payments through their own accounts, including electronic payment system accounts, bank accounts, and credit and debit cards. **In accordance with KYC («Know Your Customer») policy, our employees are authorised to carry out customer verification. In this case, the customer is required to provide the following information.** > Information about the services for which the funds were received; > > A screenshot confirming the receipt and withdrawal of funds; > > Additional information that may be requested; We reserve the right to refuse to process a transaction at any stage if it is suspected to involve money laundering or other criminal activity. #### 7. Restricted activities and clients To mitigate and control ML risk related to client, Website does not provide services and refuse account opening for the following clients with unacceptable risk level **Private individuals with the following personal and/or business activity** > information of the negative nature is available about the client, which indicates their possible relation to the proceeds of crime or laundering or terrorism if the information is received from trusted sources, such as World Check and public authorities websites; > > client funds have previously been frozen or arrested in connection with suspected criminal activity; > > reinsurance services, when the service provider is not properly licensed and there is a lack of supervision of the service provider; > > the client is trying to avoid the provision of information or is trying to hide their economic activity; > > trafficking in arms and ammunition; > > economic activity, that has to be registered in the legal entity form; > > unlicensed foreign currency exchange intermediary services (such as forex dealers, Binary options), as well as other unlicensed investment services; > > client's transactions or payments are complex, unusually large for the customer's economic or personal activity or are unclear in terms of their legal and economic objective; > > Escort services organisation / activities and / or distribution of erotic / pornographic videos and pictures and other related services; > > Cash collection services; > > Debt recovery services provider; > > Drugs, vitamins and nutritional supplements distribution; > > Detective services provider; > > Direct marketing services provider; > > Pyramid schemes; > > Telemarketing; > > Pawnshop services provider; > > Auctions and related services provider; > > Tobacco and alcohol products distribution. **Legal persons with the following personal and/or business activity:** > the client is trying to avoid the provision of information or is trying to hide their economic activity; > > information of the negative nature is available about the client, which indicates their possible relation to the proceeds of crime or laundering or terrorism if the information is received from trusted sources, such as World Check and public authorities websites; > > client funds have previously been frozen or arrested in connection with suspected criminal activity; > > reinsurance services, when the service provider is not properly licensed and there is a lack of supervision of the service provider; > > trafficking in arms and ammunition; > > investment services and investment ancillary services, when the service provider is not properly licensed in the European Economic Area or in another country, where the legislative requirements of anti-money laundering and terrorism financing are equivalent to the European Union legislation; > > legal entities, which are recognized as shell companies; > > unlicensed gambling services organization; > > the reason for the client's legal entity's establishment is unclear and the client of the legal and the information about the client's economic objectives are vague and ambiguous; > > unlicensed foreign currency exchange intermediary services (such as forex dealers, Binary options); > > client's transactions or payments are complex, unusually large for the customer's economic or personal activity or are unclear in terms of their legal and economic objective; > > Escort services organisation / activities and / or distribution of erotic / pornographic videos and pictures and other related services; > > Cash collection services; > > Debt recovery services provider; > > Drugs, vitamins and nutritional supplements distribution; > > Detective services provider; > > Direct marketing services provider; > > Pyramid schemes; > > Telemarketing; > > Pawnshop services provider; > > Auctions and related services provider; > > Tobacco and alcohol products distribution In accordance with the internal AML/CFT procedure, Website has customers in two risk categories - low-risk and high-risk customers. For high-risk customers, EDD should be carried out. **A high-risk client is someone:** > who is politically exposed person, his/her family member or a close associate; > > with whom financial claims and either arising out of or related obligations exceed 10 000 $ CAD; #### 8. Sanctions Website is prohibited from transacting with individuals, companies and countries that are on prescribed Sanctions lists. Website will therefore screen against the relevant sanctions lists in the jurisdictions in which we operate. **Website has no AML Risk Appetite for establishing or maintaining a customer or a counterparty relationship with a natural person or legal entity designated on any of the below lists or where otherwise prohibited by applicable law or regulation:** > sanction lists administered by the United States Office of Foreign Assets Control (OFAC), > > the United Nations Security Council Sanctions List (UN); > > the Consolidated List of European Union Financial Sanctions (EU); > > including the List of Specially Designated Nationals and Blocked Persons; > > any other sanctions list. In addition, Website pays particular attention to entities from countries which are on the list of noncooperative countries and territories drawn up by the Financial Action Task Force (FATF) and to monetary operations or transactions performed by or on behalf of them. #### 9. List of non-serviced countries **Website does not open accounts and does not provide services to clients from the following countries:** > Islamic Republic of Afghanistan AF > > Republic of Angola AO > > Belarus BY > > Bosnia and Herzegovina BA > > Republic of Botswana BG > > Commonwealth of The Bahamas BS > > Kingdom of Cambodia CM > > Republic of Burundi BI > > Democratic Republic of the Congo CD > > Central African Republic CF > > Republic of the Congo CG > > People's Democratic Republic of Algeria DZ > > Republic of Ecuador EC > > State of Eritrea ER > > Federal Democratic Republic of Ethiopia ET > > Republic of Ghana GH > > Republic of Guinea GN > > Republic of Guinea-Bissau GW > > Co-operative Republic of Guyana GY > > Republic of Haiti HT > > Republic of Iraq IQ > > Islamic Republic of Iran IR > > Japan JP > > Republic of Kenya KE > > Democratic People's Republic of Korea KP > > Lebanese Republic LB > > Republic of Liberia LR > > Libya LY > > Republic of the Union of Myanmar MM > > Federal Republic of Nigeria NG > > Islamic Republic of Pakistan PK > > Republic of Serbia RS > > Russian Federation RU > > Republic of the Sudan SD > > Democratic Socialist Republic of Sri Lanka SL > > Federal Republic of Somalia SO > > Republic of South Sudan SS > > Syrian Arab Republic SY > > Republic of Tunisia TN > > Republic of Trinidad and Tobago TT > > Ukraine UKR > > Republic of Uganda UG > > United States of America US > > Republic of Vanuatu VU > > Bolivarian Republic of Venezuela VE > > Republic of Yemen YE > > Republic of Zimbabwe ZW #### 10. Monitoring for suspicious activity Website AML policy includes customer's and beneficial owner's due diligence and ongoing AML monitoring and AML reporting policies. At various points in time, Website may request information regarding the transactions carried out through the customer's account opened at Website and the parties of the respective payment. If the customer may not respond sufficiently or within a timely manner, the Website also reserves the right to reject any respective payments subject to the requirements of the applicable AML laws and regulations. # Verification & Limits # Terms of Use Old These Terms of Service ("Terms") constitute a legal agreement between You ("Merchant" or "You"), XXX and a company registered under the laws of XXX and having its registered address at XXX ("Company" or "We"), governing your use of the services provided by the Company (the "Services"). By accessing or using the Services, You agree to be bound by these Terms. ### 1 GENERAL CONDITIONS 1.1. Terms govern the use of the website (the “Website”) and all other related websites and services available on or through any of the foregoing (collectively, the "Services"). These Terms do not govern your access and use of any software, websites and services which may be made available to You under separate license terms from the third party service provider. 1.2. The current effective version of the Terms is located at the Website. Company may make changes to the Terms from time to time. When such changes are made, Company will make the updated Terms available on or through the Website. Please, check these Terms periodically for updates. Your continued use of the Services after such changes have been published on or through the Website shall constitute your binding acceptance of such changes. 1.3. Use of the Services constitutes an acceptance and confirmation of your consent to be bound by these Terms, all applicable laws and regulations, and You agree that You are responsible for compliance with and that You are compliant with these Terms and the applicable laws. If You do not agree with all these Terms, then You shall not access or use any of our Services. 1.4. In order to be able to use our Services You warrant and represent that You: \ 1.4.1. You agree that You are over 18 years old and have the legal capacity to enter into this Agreement. If You wish to avoid being bound by the Agreement, do not proceed further. \ 1.4.2. You agree that Company is not acting as your broker, intermediary, agent or advisor or in any fiduciary capacity, and no communication or information provided to You by Company shall be considered or construed as advice. 1.5. Company reserves the right to change the list of available Virtual Assets at any time without prior notice. Therefore, the ability to execute a specific Transaction depends on the availability of a specific Virtual Asset ### 2 DEFINITIONS 2.1. Company (We): Software and Website operated by NNN. XXX, company registered under the laws of XXX and having its registered address at XXX ("Company" or "We") governing your use of the services provided by the Company (the "Services"). 2.2. Merchant (You): Merchant selling goods or services or a payment gateway operator or payment integrator. 2.3. Website: ; 2.4. VA: virtual asset, such as Bitcoin. 2.5. Transaction: a transfer of VA or reverse transfer in case of refund for cancelled sale. 2.6. The Services: nature of services provided is described in Section 3 of these Terms. 2.7. Agreement: Terms form and agreement between Company and You. 2.8. User/Users: any entity/entities who is using the Services to send VA Transactions to Merchant. ### 3 PROVISION OF SERVICES 3.1. The following Services are available to Merchants through Website: \ 3.1.1. Payment processing in VA; 3.2. Please note that some or all of these Services could be provided by Third Parties. 3.3. The Services do not include: \ 3.3.1. payment services in fiat currencies; \ 3.3.2. management of fiat assets, including fiat deposits; \ 3.3.3. management of other financial instruments, including but not limited to VAs; \ 3.3.4. investment or investment advisory or similar activities; \ 3.3.5. the activity of investing assets collected by means of a proposal to conclude an agreement to participate in any venture. ### 4 PAYMENT PROCESSING IN VIRTUAL ASSETS 4.1. VA payments are: VA Transactions to Merchant. Company notes that these do not include fiat payment services. 4.2. In order to undertake a Virtual Asset payment, Company provides the User with the data for such payment. The data for a Virtual Asset payment includes the amount, selected Virtual Asset and the wallet address to which the payment has to be made. Please note, that this deposit address may be generated by Third Party service provider at the time of the transaction. Only payout address corresponds to the Merchant's balance or their designated wallet. Payout address is not visible to the User. 4.3. Merchant or User initiate a payment request by its generation, which may be in the form of a payment link or a simplified payment request. The payment request shall include essential transaction details, such as the transaction amount, required Virtual Asset and additional metadata. Merchant retains the discretion to decide whether to include metadata or not for tracking and reference purposes. 4.4. Upon confirmation of the transaction in the blockchain, the funds of User are successfully credited to the designated deposit address. Subsequently, following confirmation in the blockchain, processing takes place. Once processing is successfully completed, the funds are promptly displayed on the Merchant's balance or deposited into your payout address. 4.5. Transaction is carried out according to the rate determined at the time the Virtual Asset payment order is initiated. Company reserves the right to determine the exchange rate of Virtual Assets at their own will at any given time. 4.6. To mitigate payment challenges, it should be noted that the minimum payment amount varies for each VA and is subject to modification based on the blockchain condition at the time of transaction initiation. 4.7. Company charges fees for the currency exchange services in the form of commission from Company, which is already included in the Virtual Asset exchange rate. Therefore, offered Virtual Asset exchange rate includes all fees for the payment. 4.8. As part of each payment, Users are informed of the total amount of the payment (including fees). This payment amount is valid for N minutes from the start of the payment process. 4.9. Merchant is solely responsible for ensuring due diligence on their Users in order to prevent facilitating services for illicit purposes. 4.10. In line with European regulations and our duty to monitor blockchain transactions, Company reserves the right to temporary block Virtual Assets, when the source of such funds from User is detected as high risk or illicit. 4.11 Users may be required to provide identity documents (such as passport or ID card), address verification, and information about beneficial owners for legal entities. Company reserves the right to request verification of the user's identity at any time using photo and/or video verification. In adherence to commonly accepted KYC standards, Company takes measures to identify and restrict the provision of its Services to politically exposed persons (PEPs). 4.12. Merchant is solely responsible for ensuring that 4.11 is clear to User before making the payment. ### 5 TRANSACTION LIMITS 5.1. We impose daily and monthly Transaction processing limits and limits on individual Transactions unless specified otherwise. These Transaction limits may be set and changed by the Company at any time without prior notice. 5.2. You agree to adhere to the applicable Transaction processing limits. We may not process any Transactions that overreach the limits, and such refusal to process them does not constitute a breach of this Agreement. ### 6 PROHIBITED JURISDICTIONS 6.1. Before using our Services, please ensure that cryptocurrency usage is not prohibited in your country. It is your responsibility to check your eligibility for using our service. 6.2. Use of the Services is void where prohibited by the applicable law and the laws of the relevant jurisdictions. 6.3. Company maintains the right to select its markets and jurisdictions to operate in and may restrict or deny its Services to certain countries. 6.4. Company also maintains the right to use various methods to prevent the use of the Services by the Merchants listed above. You shall comply with this Section 6, even if Company's methods to prevent use of the Services are not effective or can be bypassed