Skip to main content
A payment link is a checkout URL you create in the Merchant Portal and send to a customer. Nothing has to be integrated on your side: Waffo creates the order, hosts the payment page, and shows you the result in the Portal. Find it under Transactions → Payment Link. Creating links is permission-controlled — the New Payment Link button is disabled for users who do not hold that permission. If you can open the page and the button is active, the feature is enabled for your account. The two are the same rails, not two products: a payment link is created through the same order-creation path as an API order, and the URL you copy is the same hosted payment page that orderAction.webUrl returns to an API integration. What differs is who creates the order — the Portal, or your server. Product must be one that is enabled on your Payin contract — check Service → Payin in the Portal. A product that is not in your contract fails validation, the same way it would on /api/v1/order/create. On submit you get a confirmation dialog with the description, amount and currency, the country, and the link itself with a copy button. Copy it there and share it — that is the moment the link is handed to you.
  • Leave Order Expired At empty and the default order-expiry window configured for your account applies. The Portal surfaces that default in the tooltip on the Order Expired At column.
  • Pick a date and time to override it. The picker blocks days in the past; an expiry that has already passed by the time the request is processed is ignored and the default applies instead.
  • Give the payer usable room. A window of only a few minutes is accepted but leaves almost no time to complete a payment — especially for methods that involve a bank app or an over-the-counter step.
After expiry the underlying order reaches its final state (ORDER_CLOSE) and the link no longer completes a payment. Expiry is the only lapse mechanism the page offers. No revoke button. The list’s only row action is Copy URL. If you need to close a link early and you have an API integration, cancel the underlying order with POST /api/v1/order/cancel using the acquiringOrderId shown in the list — cancellation is possible while the order is still open, not after it has succeeded. Otherwise, set a short expiry when you create the link. No reuse. Each link is created together with exactly one order: Treat a link as a single invoice, not as a reusable “pay me” page. Because the object behind it is a normal acquiring order, everything downstream behaves normally: it appears in Transactions → Payments, is searchable there by Acquiring Order ID, and is refunded, reconciled and settled like any other order. The Payment Link list shows, newest first: Status values are the order statuses you already see in Transactions → Payments: AUTHORIZATION_REQUIRED (link issued, payer has not finished), PAY_IN_PROGRESS, AUTHED_WAITING_CAPTURE, CAPTURE_IN_PROGRESS, PAY_SUCCESS, and ORDER_CLOSE (closed, including expired and abandoned links). This page is a creation log, not an analysis view: it has no filters and no export. For filtering, transaction detail, refunds and receipts, work from Transactions → Payments with the Acquiring Order ID. Creation runs the same validation as API order creation, so the usual causes apply: a product, country or currency that is not enabled on your contract, or a payment-method combination your account cannot serve. The error message names the offending parameter — check it against your Service → Payin page first.
Need behaviour this page does not cover — reusable links, your own order ID on the order, or programmatic creation? That is what the API integration path is for. Contact support with the Acquiring Order ID when a specific link misbehaves.