FAQs (Frequently Asked Questions)

A payment link is a secure, shareable URL that lets your customer pay you without visiting your website or app. You create the link in the PayU Dashboard or via API, share it over any channel such as email, SMS, or WhatsApp. Your customer clicks it to pay on a PayU-hosted checkout page. Once paid, you receive a notification and the transaction appears in your Dashboard.

See How Payment Links Works for the end-to-end flow.

No. Payment Links is a no-code product. You can create, share, and manage links entirely from the PayU Dashboard. The Payment Links API is available for merchants who want to automate link creation inside their own systems, but it is optional.

No. Payment Links is a completely standalone product. You do not need a website, app, or any prior PayU integration to start using it. You can create and share payment links directly from the PayU Dashboard with out any code or technical setup.

If you later integrate PayU Hosted Checkout or Merchant Hosted Checkout on your website, Payment Links remains available alongside those integrations.

Customers can pay using payment methods enabled on your merchant account:

• Credit/Debit cards (Visa, Mastercard, RuPay, and Amex)
• UPI (GPay, PhonePe, Paytm, etc.)
• Net Banking (50+ banks)
• Wallets (Paytm, Mobikwik, and Freecharge)
• EMI (no-cost and standard)
• BNPL

Contact PayU support to enable or disable specific methods on your account.

UPI must be enabled on your merchant account. If you can see UPI when you test the link and not your customer while making the payment, ask them to try a different browser or device.

If UPI is missing for all customers, contact PayU support to confirm that UPI is active on your merchant account.

UPI Intent (direct app redirect): if you want to direct your customers straight into a UPI app without entering their VPA, you should enable UPI Intent. Contact your PayU KAM for guidance.

No. Payment Links do not support bank-level or card-issuer-level restrictions (for example, Union Bank credit cards only). The checkout page shows all payment methods active on your account.

If your use case requires restricting the checkout to a specific payment method or issuer, consider Server-to-Server (S2S) integration, which gives you more control over the checkout experience. Contact your PayU KAM for guidance.

Yes, but you should first enable international payments on your merchant account.

To enable international payments:

1. Contact your PayU Key Account Manager to enable international payments for your MID.
2. Once enabled, use the currency parameter in the Create Payment Link API to specify the currency (for example, "currency": "USD").
   

PayU supports card payments from over 150 countries and offers Dynamic Currency Conversion (DCC), which allows your international customers to pay in their preferred local currency.

Dashboard:

Watch out!

• The currency selection option is not available in the Dashboard unless international payments are active on your account. If you do not see it, raise a request with your key account manager.
• International currency payments apply only to card transactions. UPI, Net Banking, and Wallets are in INR.

Yes. PayU Payment Links are PCI DSS compliant. PayU uses advanced encryption and tokenisation to protect customer payment data. No card or bank details pass through your systems.

Yes. Each link has its own amount field. You can also leave the amount flexible so the customer fills it in at checkout You can use this use case for donations or open-ended collections.

Yes. You can add standard fields (name, email, phone, address) and fully custom fields (any label, any type) to the checkout page. See Create a Payment Link for details.

Even when you pass customerEmail and customerPhone in the API request, PayU may still prompt the customer to enter them if the Additional Customer Details fields are configured to capture email and phone on the checkout page.

To prevent this, do not add email and phone as custom checkout fields in your link configuration. If you are using the API, omit these fields from the Additional Customer Details section of the payload. If you created the link via the Dashboard, check that you have not toggled on the email/phone fields under Additional Customer Details.

Custom fields are visible on the checkout page only when the link is opened in a browser. To confirm they are configured correctly:

1. Open the link in a browser (not the Dashboard preview).
2. Check that the fields were added under Additional Customer Details → Add New Fields+ during creation.
3. Confirm the field type is set correctly (Alphanumeric, Calendar, or Dropdown).
   

If the fields are still missing, the most common cause is that they were added after the link was already created. Note that Payment Links cannot be edited after creation. Duplicate the link, add the custom fields before clicking Create and Send Payment Link, then deactivate the original.

See Custom Checkout Fields for details.

Yes. The default expiry is 1 year. You can set any future date during creation. Once expired, the link cannot accept payments.

To extend expiry after creation via API, use the Cancel / Change Status API with an updated expiryDate. From the Dashboard, you cannot extend expiry directly. You should duplicate the link with a new expiry date and deactivate the original.

The expiryDate parameter must be in IST (Indian Standard Time) using the format YYYY-MM-DD HH:MM:SS.

Example: "expiryDate": "2026-12-31 23:59:59"

Do not use UTC or any other timezone offset. If you send a UTC timestamp, the link expiry will be calculated incorrectly and may expire earlier or later than you intended.

Yes. Use the Max Transactions field when creating the link. Leave it blank for unlimited. Once the limit is reached, the link automatically deactivates.

You cannot edit a link's amount, description, or configuration from the Dashboard after creation. To correct a mistake, duplicate the link with the right details, then deactivate the original.

Via API, you can update active status, expiryDate, subAmount, tax, shippingCharge, and isPartialPaymentAllowed using the Cancel / Change Status API.

Yes, if you enable Partial Payment on the link. The customer can pay any amount less than the total — you cannot specify a minimum partial amount. For structured auto-debiting, use Recurring Payments.

Yes, but through a separate Subscription Payment Link flow — not the standard /payment-links API.

Using the Dashboard:

1. Log in to the PayU Dashboard.
2. Go to Subscriptions → Create Subscription Link.
3. Set the purpose, billing type (Fixed Amount or Maximum Amount), and subscription period.
4. Share the link — the customer completes mandate registration (eNACH or UPI Autopay) on the PayU-hosted checkout page.

Using the API:
You can pass si=1 and si_details parameters when creating a payment link via API to register a UPI Mandate. This requires Standing Instruction (SI) to be enabled on your merchant account — contact your PayU account manager to activate it.

Key difference: a standard Payment Link collects a one-time payment. A Subscription Payment Link registers a mandate that authorises PayU to auto-debit your customer on a recurring schedule.

📘

SI / eNACH activation is required before using subscription links. Contact your PayU account manager or raise a request via the Dashboard Help section.

This happens when your PayU account's Display Name is not set separately from your login name. To fix it:

1. Log in to the PayU Dashboard.
2. Click the drop-down at the top-right corner (your login name).
3. Select Profile.
4. Go to the Business Details tab.
5. Update the Display Name field to your company or business name.
6. Save the changes.

The updated Display Name will appear on all payment pages, including those opened via payment links.

There is no hard limit on the number of payment links. For creating hundreds at once, use the Bulk Upload feature or the Create Payment Link API.

You can share a payment link in three ways:

• Copy the URL from the Dashboard and share it over any channel (WhatsApp, email, etc.)
• Send it directly from the Dashboard via SMS or email — enter the customer's phone/email at creation and toggle notifications on
• Reshare an existing link at any time from Actions → Share

Yes. A single link can be opened and paid by different customers, up to the Max Transactions limit (unlimited by default). For a personalised link pre-filled with a specific customer's details, create one link per customer.

Yes. You can manually copy the link URL from the Dashboard and share it over WhatsApp like any other URL — no special setup required.

For automated WhatsApp delivery at scale, PayU offers Enhanced Payment Links (EPL) on WhatsApp, which sends an approved WhatsApp Cloud API template message with a "Pay Now" button that carries the PayU payment link. This requires a separate WhatsApp Business API integration.

See WhatsApp Payment Link Integration for setup details.

The three most common causes:

1. Mobile number was not included.
For Dashboard links: confirm you entered the customer's mobile number in the Customer Details section and toggled Notify via SMS on before creating the link.
For API links: confirm your request payload includes the mobileNumber field. PayU triggers SMS only when the mobile number is present in the create-link request — it is not optional if you want SMS delivery.

2. DND (Do Not Disturb) is active on the customer's number.
DND blocks all promotional and transactional SMS from every sender. Ask the customer to check their DND status with their mobile operator, or share the link via WhatsApp or email instead.

3. Notifications fire once at creation only.
SMS cannot be re-triggered for an existing link. To resend, go to Actions → Share in the Dashboard and send the link again manually, or share the URL directly.

Check the following:

1. Confirm the customer's email address was entered correctly — open the link Details view in the Dashboard.
2. Confirm Notify via Email was toggled on at the time of creation. Notifications fire once at creation only — they cannot be re-triggered.
3. Ask the customer to check their spam or junk folder.

To resend, go to Actions → Share in the Dashboard and re-send via email, or copy the URL and share manually.

No. When creating a payment link from the Dashboard, you cannot set a per-link successUrl or failureUrl. Dashboard-created links redirect customers using the merchant account-level redirect URLs configured in your PayU account settings.

If you need per-link redirect URLs (for example, to redirect each customer to a different order confirmation page), use the Create Payment Link API and pass successUrl and failureUrl in the request payload.

🚧

The API uses successUrl and failureUrl — not surl and furl. Using the wrong names will cause redirect failures. See the API Usage section below.

The link status in the Dashboard changes to Paid (or remains Active with a non-zero totalRevenue for partial-payment links). The transaction appears in the Transactions tab in the Dashboard.

If you have webhooks configured, you receive a real-time payment.success event. See Webhooks: Receive & Verify.

This is expected behaviour. A newly created payment link has no transactions yet, so status-related fields like totalRevenue, totalAmountCollected, and transaction counts will be empty or zero until a customer attempts a payment.

The link itself is immediately Active after creation — use the Fetch Single Payment Link API (by invoice number) to confirm the link was created and check its current status.

"PENDING" status: PENDING is a transaction status (a payment in progress at the bank), not a link status. A link with no transactions will never return PENDING — it returns Active.

If you get a completely empty response body with HTTP 200 on the create-link call, verify that all required fields in your payload are correctly formatted. Check the invoiceNumber uniqueness and ensure the Authorization header carries a valid, unexpired Bearer token.

The link remains Active and the customer can try again — either immediately or later. A failed attempt does not count against the Max Transactions limit.

This is almost always a configuration issue with your redirect URLs. Check the following:

1. Confirm the parameter names are correct.
The Payment Links API uses successUrl and failureUrl — not surl and furl. Using the wrong names causes a blank screen or redirect failure after payment.

2. Confirm your redirect URLs are whitelisted.
Your successUrl and failureUrl domains must be registered in your PayU merchant account. Contact PayU support or your account manager to whitelist them.

3. Check the link status.
If the link is expired or deactivated, the payment page will not load. Verify the link is Active in the Dashboard.

If the issue is intermittent, it may be a network or browser issue on the customer's end. Ask them to try on a different browser or device.

Hash mismatch means the hash you are computing locally does not match what PayU sent in the response. The most common causes:

1. Wrong hash formula.
The Payment Links response hash uses the reverse of the payment request hash. The formula is:
sha512(SALT|status||||||udf5|udf4|udf3|udf2|udf1|email|firstname|productinfo|amount|txnid|key)

2. Extra spaces or encoding differences.
Compute the hash from the exact values in the response — do not trim or re-encode any field.

3. Using the wrong SALT.
Ensure you are using the SALT that corresponds to the key in the response.

4. Split payment payload.
If you are using aggregatorSplitInfo or aggregatorCharges in your create-link request, verify that split settlement is enabled on your account. Attempting split settlement on an account that hasn't been onboarded for it can produce unexpected response fields that break hash verification. Contact your PayU account manager to confirm it is activated.

Check these in order:

1. Webhook URL must be registered.
Your webhook endpoint must be configured in the PayU Dashboard under Settings → Webhooks, or whitelisted by your PayU account manager. PayU does not send events to unregistered URLs.

2. Your endpoint must return HTTP 200.
PayU retries delivery if it receives anything other than a 2xx response. Check your server logs to confirm the endpoint is receiving the request and responding correctly.

3. Verify the webhook hash.
If your hash verification logic rejects the event, it will appear to "not arrive" in your app even though PayU sent it. To confirm whether PayU sent a webhook for a specific transaction, contact PayU support with the txnid and mihpayid — the integration team can pull webhook delivery logs.

4. Check firewall rules.
Ensure your server allows inbound requests from PayU's IP ranges.

Yes. Find the transaction in the Transactions tab and initiate a refund from there. The refund process is the same regardless of how the payment was collected.

Payment Links APIs use OAuth2 Bearer token authentication — separate from your standard PayU key + salt + SHA-512 hash. You need a Client ID and Client Secret to generate a token.

See Authentication (Token).

Your production Client ID and Client Secret are in the PayU Dashboard:

1. Log in to PayU Dashboard
2. Go to Settings → API Keys (or Developer Settings, depending on your dashboard version)
3. Your Client ID and Client Secret are listed there alongside your Key and Salt.

If you do not see them, your account may not have Payment Links API access enabled. Contact your PayU account manager or raise a request via the Dashboard Help section.

For UAT testing, your UAT Client ID and Client Secret are provided separately by the integration team with your UAT credentials. Do not use production credentials in UAT and vice versa.

🚧

Never share your Client Secret in public code repositories, client-side JavaScript, or mobile app binaries. Store it server-side only.

Payment Links APIs use different base URLs for UAT and production:

Using a UAT token against the production endpoint (or vice versa) will return a 401 Unauthorized error. Confirm you are using matching credentials and URLs for the same environment.

Request multiple scopes in one token by separating them with spaces: create_payment_links update_payment_links read_payment_links.

Tokens expire after the number of seconds in the expires_in field — typically 3600 (1 hour). A token is valid for multiple API calls until it expires or is revoked — you do not need a new token per request. Generate a new token before it expires and do not hard-code tokens in your application.

A 401 error almost always means one of:

• Token expired — tokens are valid for ~1 hour. Generate a new token and retry.
• Wrong environment — you are using a UAT token against the production endpoint, or vice versa. See the endpoint table above.
• Missing or wrong scope — the token was generated without the scope required for the operation. Check the scopes table above and regenerate the token with the correct scopes.
• Token revoked — if the token was explicitly revoked, generate a new one.

The Payment Links API does not use the shorthand furl and surl (those are used in the standard PayU Hosted Checkout integration). Use failureUrl and successUrl instead in your create-link payload.

Each payment link must have a unique invoiceNumber within your merchant account. Either use a different value, or omit invoiceNumber entirely — PayU will auto-generate a unique one.

The fromDate and toDate parameters are mandatory for the Fetch All Payment Links API because the API retrieves a list of links across a date range. Without these bounds, the response could include thousands of records and become prohibitively large.

To fetch a specific link without date parameters, use the Fetch Single Payment Link API instead — it takes only the invoiceNumber as a path parameter and returns that link's full details immediately, with no date range required.

No. UDF (User Defined Fields) values passed in your create-link API request are not displayed to customers on the PayU-hosted checkout page. They are server-side metadata — they travel with the transaction and appear in your transaction reports, webhook payloads, and the Fetch Payment Link API response, but customers never see them.

Use UDFs to pass your internal order IDs, customer segments, product codes, or any reference data you need for reconciliation.

TPV is not configured during payment link creation — it is enforced at the payment page level when the customer selects a payment method.

To restrict a payment link's checkout to TPV-verified accounts (for example, accepting Net Banking only from a customer's registered account), use the enforcePayMethod parameter when creating the link. TPV must be enabled on your merchant account before you can use it.

TPV is primarily used for subscription or mandate-based flows (SI / UPI Autopay), not standard one-time payment links. Contact your PayU account manager to confirm whether TPV is active for your MID and to understand the applicable payment methods.

This error means your merchant account is configured as an aggregator but split settlement has not been activated for your account.

If you are using aggregatorSplitInfo or aggregatorCharges in your create-link payload, split settlement must be explicitly enabled by PayU. Contact your PayU account manager to activate split settlement for your MID.

Yes, but it requires prior activation. Split settlement lets you distribute a single payment across multiple sub-merchants or accounts using aggregatorSplitInfo in the create-link API payload.

Prerequisites:

1. Your account must be onboarded as an aggregator with split settlement enabled — contact your PayU account manager.
2. Child merchant accounts must be onboarded and approved before you can route payments to them.
3. Test split settlement in UAT before going to production.

Attempting to use aggregatorSplitInfo without activation will return the "Transaction initiation not allowed on aggregator" error.