June 2026
Discover PayU payment capabilities, API enhancements, and integration changes for August 2026. This changelog is for merchants and developers integrating PayU APIs. Availability can depend on merchant activation, payment-method support, or eligibility described in the relevant entry.
APIs
RuPay and AMEX authentication values for Save a Card
Product: Card tokenisation
Feature/API: Save a Card and Provision Alt ID
Impact: Medium
Breaking Change: No
Action Required: Review integration
Summary
Save a Card requests support the authentication references required for RuPay and AMEX flows. Provision Alt ID no longer requires the affected field to be sent as mandatory.
Why this matters
Mapping the correct authentication value from the authorisation response helps the card-saving flow distinguish the applicable RuPay or AMEX scenario.
Who is affected
- Merchants saving RuPay or AMEX cards.
- Developers handling RuPay BePG or RuPay SecureNxt Card Tokenization.
- Merchants integrating Provision Alt ID.
What's new
var9is mandatory for RuPay and AMEX cards in Save a Card.- For RuPay BePG, pass the Authentication Reference Number (AuthRefID).
- For RuPay SecureNxt Card Tokenization, pass the DS Transaction ID.
- For AMEX, use the authorisation reference number or the AEVV received during the authorisation call, as applicable to the documented flow.
- Provision Alt ID treats the affected field as optional.
Action required
Review the mapping from each applicable authorisation response to var9. Do not reuse a reference from one card network for another, and do not expose authentication values in client-side code or logs.
Need to migrate
Review required for integrations that save RuPay or AMEX cards, or that send the affected Provision Alt ID field. Other card-tokenisation flows are unchanged.
Related documentation
PACB Virtual Accounts for local INR collections
Product: PayU Cross-Border Payments
Feature: Virtual Account-based local collections
Impact: Medium
Breaking Change: No
Action Required: Optional
Summary
PACB supports managing Virtual Accounts for local INR collections. Payers can transfer INR to the account using NEFT, RTGS, or IMPS; PayU confirms the credit, holds it until required trade data is submitted and approved, and then settles the approved payment.
Why this matters
Global Payment Service Providers can provision and manage collection accounts for sub-merchants and reconcile the resulting deposits through APIs.
Who is affected
- Global PSPs integrating PACB Virtual Account collections.
- Developers managing Virtual Accounts for sub-merchants.
- Teams processing incoming credits, on-hold payments, and settlement status.
What's new
- Create a Virtual Account with
POST /payout/v2/virtualAccounts. - List a merchant's Virtual Accounts with
GET /payout/v2/virtualAccounts; the documentedpageSizemaximum is 50. - Update a Virtual Account with
PATCH /payout/v2/virtualAccounts?virtualAccountId=.... - Send at least one of
virtualAccountNameorisActivein an update. SettingisActivetofalsedeactivates the account and blocks new bank credits; historic account and deposit details remain available through the documented list and transaction APIs. - The documented collection journey includes sub-merchant onboarding, Virtual Account management, credit confirmation, on-hold handling, and settlement.
- The local-collection guide documents a transaction limit of INR 25,00,000; a transfer above that amount is rejected.
Action required
If you are adopting PACB collections, implement the create, list, and update/deactivate operations, handle the on-hold state and settlement journey, and enforce the documented transaction limit in your payment workflow.
Need to migrate
No migration is required for unrelated integrations. A new PACB integration requires the environment-specific endpoint and authentication described in the API references.
Related documentation
Get Transaction Details API
Product: Direct Integration
Feature/API: Get Transaction Details V4
Impact: Medium
Breaking Change: No
Action Required: Optional
Summary
Get Transaction Details API retrieves transaction details between two dates. The response returns the API status and transaction records in an array.
Why this matters
Merchants can retrieve a date-bounded set of transaction details for operational reporting and reconciliation through the documented API contract.
Who is affected
- Merchants using direct integration transaction reporting.
- Developers building reconciliation or reporting jobs.
- Existing users of other transaction-status APIs who need a date-range transaction view.
What's new
- Submit the initial date in
var1and the final date invar2. - Use the
get_Transaction_Detailscommand. - Call the documented
merchant/postservice?form=2endpoint for the applicable environment. - A successful response contains
Transaction_detailsas an array; an empty array indicates that no transactions were found for the range. - Dates use the documented
yyyy-mm-ddformat. An invalid date returns a validation message rather than transaction results.
Action required
Add the V4 contract to date-range reporting jobs, validate the date format before sending requests, and handle both a successful response with records and a successful response with an empty array.
Need to migrate
No migration is required for integrations that do not need this reporting capability. Teams adding date-range retrieval should implement the documented command and endpoint contract.
Related documentation
Integration Guide
LazyPay Pay-in-3 checkout flow
Product: LazyPay Pay-in-3
Feature: Eligibility and three-instalment checkout
Impact: Medium
Breaking Change: No
Action Required: Optional
Summary
Eligible customers can split a purchase into three equal instalments. The first instalment is collected at checkout, the remaining two are auto-collected in the second and third month, and the merchant receives the order value upfront.
Why this matters
Pay-in-3 gives merchants a defined eligibility and repayment flow while allowing an eligible order to proceed without waiting for later instalments.
Who is affected
- Merchants adding LazyPay Pay-in-3 to a custom checkout.
- Developers implementing the eligibility and Merchant Hosted Checkout flow.
- Customers whose Pay-in-3 eligibility is returned by PayU's checkout-details flow.
What's new
- Use Get Checkout Details (
get_checkout_details) before Collect Payment (/_payment) to check the available Pay-in-3 option. - Request Pay-in-Parts lenders with
filters.paymentOptions.emi.payInPartsset to"all"when required by your request pack. - The eligibility response distinguishes Existing to Bank (ETB) and New to Bank (NTB) handling.
- For an eligible ETB customer, the response can provide the down payment, second- and third-instalment amounts and dates, and applicable fee details.
- For an NTB customer, collect the documented personal information and call Get EMI Checkout Details for the full eligibility and repayment result.
- For an eligible Merchant Hosted Checkout payment, use
pg=EMIandbankcode=LZYPI3. - The customer pays the first instalment at checkout. The remaining two instalments are automatically collected, while the merchant receives the full order value upfront.
Action required
For a new Pay-in-3 integration, add the pre-payment eligibility check, present the returned repayment schedule, handle the ETB and NTB paths, and pass bankcode=LZYPI3 when the customer is eligible. Do not display Pay-in-3 as an available option without an eligible response.
Need to migrate
No migration is required for existing payment methods. Merchants adopting Pay-in-3 must implement the documented eligibility flow; availability remains subject to the customer's eligibility and the supported request path.
Related documentation
Advantage Club payment option for Merchant Hosted Checkout
Product: Merchant Hosted Checkout
Feature: Advantage Club payment routing
Impact: Low
Breaking Change: No
Action Required: Optional
Summary
Merchant Hosted Checkout supports Advantage Club as a wallet payment option. Use pg=RD with bankcode=ADVCLUB when routing an Advantage Club payment.
Why this matters
Your checkout can send the payment-category and wallet code that PayU expects for Advantage Club instead of treating it as a generic wallet route.
Who is affected
- Merchants adding Advantage Club to Merchant Hosted Checkout.
- Developers maintaining payment-option and bank-code mappings.
- Existing integrations that do not offer Advantage Club are unaffected.
What's new
- Set
pgtoRDfor Advantage Club. - Set
bankcodetoADVCLUB. - Continue to use the wallet-specific bank code for other wallet options.
Action required
If you are adding Advantage Club, update the payment-option mapping to send both values. Keep merchant authentication material server-side when constructing the request.
Need to migrate
No migration is required for existing wallet options. This is backward-compatible for integrations that do not use Advantage Club.
Related documentation