Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.iterapay.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

A Static invoice is designed for multiple uses without a strict expiration time and payment amount. It is ideal for donations, account top-ups, or flexible payments where the client decides the final amount to send (often with a predefined minimum limit).

​
Stage 1: Selecting a payment method

When a client opens a static invoice link, the interface is similar to a one-time invoice, but adapted for flexible payments.

​
Order details (Left panel)

  • Name and Minimum Amount: Displays the invoice title (e.g., “Charity”) and the minimum acceptable amount (e.g., “from $20”).
  • Description: Details of the purpose (e.g., “Pets shelter”).
  • Note: There is no “Quote expire” countdown timer, as the link remains permanently active.

​
Payment method selection (Right panel)

The client sees the available payment methods.
  • Unlike one-time invoices, the cards do not show an exact, locked cryptocurrency amount. Instead, they display the minimum fiat equivalent required for that method (e.g., “from $20” for USD Coin on Ethereum).
  • Action: The client selects the preferred cryptocurrency and clicks Pay now.
Screen 25

​
Stage 2: Transferring funds (Payment Page)

After selecting the currency, the system generates a permanent or reusable deposit address for the client.
  • Note: Because the amount is variable, there is no “Rate fixed for” timer. The exchange rate will be calculated at the exact moment the blockchain confirms the transaction.

​
Payment details

  1. Scan to pay (QR code): The client can scan the QR code.
  2. Manual payment: * Address: The generated wallet address for receiving funds.
    • Amount: Displays the flexible requirement (e.g., “from $20”). The client manually enters the amount they wish to send directly in their own crypto wallet application, ensuring it meets or exceeds the minimum.
⚠️ Security Warning: The standard strict network warning is displayed (e.g., “Only send USDC ERC20 to this address”). Sending assets via the wrong network results in the irreversible loss of funds.
Screen 26

​
Stage 3: Confirmation and Results

Because static invoices accept variable amounts, there are no “Overpayment” or “Partial payment” errors in the traditional sense—any successful transaction above the minimum is accepted as a valid payment.

​
Scenario A: Successful payment (Payment confirmed)

When the client sends the funds (e.g., sending $200 for a “from $20” invoice), the system processes it upon network confirmation.
  • A green checkmark appears with the status Payment confirmed.
  • A message confirms the exact amount received (e.g., “You have successfully sent 200 USD Coin”).
  • View details: Displays the TxHash, Invoice name, Invoice ID, and the Amount paid.
  • Action: The client can click Copy transaction details.
Screen 27

​
Scenario B: Payment failed

If the transaction fails on the blockchain level (e.g., out of gas, reversed by the network):
  • A red alert icon appears with the status Payment failed.
  • A message reads: “The transaction could not be completed. Please try again or contact support.”
  • View details: Displays the failed TxHash and invoice details.
  • Action: The client can click Contact support for further assistance.
Screen 30

​
Stage 4: Updating data in the Merchant’s dashboard

After the client performs the actions described above, the data in the control panel is updated automatically.

​
Invoice status changes

  • Paid: In the scenario of full payment.
  • Partially paid: In the scenario of partial payment.
  • Overpaid: If the client sent an amount exceeding the one specified in the invoice.

​
Updating financial indicators

  • Payments (Received payments): Increases by the actual amount received.
  • Expected receivables (Expected receipts): Decreases by the amount received.
Logic: The client’s obligation is considered fulfilled (fully or partially), so the amount is transferred from the “Expected” category to the “Received” category. The next step for the merchant is to consolidate the received funds (Collect function).