Weelay Overview

What Weelay is

Weelay is a non-custodial checkout for accepting payments in USDT TRC20.

The service helps a merchant create an invoice, show a checkout page to the buyer, check the incoming payment on the TRON network and send a webhook notification to the merchant.

Weelay does not hold buyer funds and does not control merchant wallets. The buyer sends funds directly to the merchant USDT TRC20 address.

Who Weelay is for

Weelay is intended for merchants who need a simple way to accept USDT TRC20 payments through a checkout page and API.

Common use cases:

• website or online store;
• manual invoice creation;
• backend integration through API;
• accepting payment for digital or regular services;
• automatic order update through webhook;
• payment status checking without building custom blockchain monitoring.

Main idea

A typical integration works like this:

1. The merchant creates a project in Weelay.
2. The merchant sets a USDT TRC20 wallet address.
3. The merchant backend creates an invoice through the API.
4. Weelay returns payment_url.
5. The buyer opens the checkout page.
6. The buyer sends USDT TRC20 to the merchant address.
7. Weelay checks the blockchain transaction.
8. The invoice receives paid, expired or another final status.
9. Weelay sends a webhook to the merchant.
10. The merchant updates the order in the merchant system.

Roles

There are three parties in the payment flow.

Merchant creates a project, sets a wallet address, creates an invoice and fulfills the order for the buyer.

Buyer opens the checkout page and sends USDT TRC20 to the merchant address.

Weelay provides the technical infrastructure: invoice, checkout page, payment checking, status and webhook.

Weelay is not a seller, bank, cryptocurrency exchange or wallet.

Non-custodial model

Weelay operates under a non-custodial model.

This means:

• funds do not pass through a Weelay balance;
• Weelay does not hold USDT;
• Weelay does not store merchant private keys;
• Weelay cannot debit the merchant wallet;
• Weelay cannot issue a refund on behalf of the merchant;
• blockchain transactions usually cannot be cancelled after they are sent.

This is explained in more detail in the Non-Custodial Payment Notice.

What an invoice is

An invoice is a Weelay record that contains the amount, currency, status, expiration time and payment link.

An invoice is used to connect the buyer payment with a specific merchant order.

Usually the merchant sends an order_id to match the Weelay invoice with the order in the merchant system.

Payment statuses

An invoice can have different statuses.

Main statuses:

• pending — the invoice is created and waiting for payment;
• paid — the payment was found and confirmed;
• expired — the payment time has expired;
• failed — the invoice cannot be completed successfully.

The merchant should fulfill the order only after the invoice status becomes paid.

Merchant API

Merchant API allows the merchant backend to work with Weelay programmatically.

Through the API, the merchant can:

• check current API key data;
• create an invoice;
• retrieve invoice list;
• retrieve a single invoice;
• use Idempotency-Key to protect against duplicates.

The secret API key must be stored only on the merchant backend. It must not be placed in frontend code, public JavaScript or public repositories.

Webhook

Webhook is a notification from Weelay to the merchant backend.

Webhook is used so the merchant can automatically learn about invoice status changes and update the order in the merchant system.

The merchant should handle webhook events idempotently, because the same event may be delivered more than once.

What is needed to start

To start, the merchant needs to:

1. Create a Weelay account.
2. Verify email.
3. Create a project.
4. Set a USDT TRC20 wallet address.
5. Create a secret API key.
6. Connect invoice creation.
7. Configure webhook endpoint.
8. Check a test payment.
9. Move to real usage.

Supported payment scope

Weelay supports payments in USDT TRC20.

Other networks, tokens, custodial balances, automatic refunds and built-in wallets are not part of the basic service model.

The merchant is responsible for the wallet, goods, services, buyer support and refunds.

Where to go next

Recommended reading order:

1. Integration Guide;
2. Merchant API;
3. Invoices;
4. Invoice Statuses;
5. Idempotency-Key;
6. Webhooks;
7. API Errors.

For legal details, see:

• Terms of Use;
• Non-Custodial Payment Notice;
• Acceptable Use Policy;
• Refund Policy;
• Merchant Complaints;
• Privacy Policy.