July 2026

Summary

Get PG Up Status returns the health of payment options and their gateways. It replaces Get Net Banking Status and can report whether an option is operational, unavailable, or performing poorly when performance reporting is requested.

Why this matters

Merchants can select or suppress payment options based on current gateway health instead of relying only on a net-banking-specific status check.

Who is affected

• Merchants checking payment-option availability before checkout.
• Developers monitoring wallets, Net Banking providers, and UPI.
• Integrations currently calling Get Net Banking Status.

What's new

• Use POST /merchant/postservice.php?form=2 with the environment-specific host documented in the API reference.
• Use var1=default to check all payment options, or pass a specific payment-option code such as a bank code, wallet code, or UPI.
• up_status=1 means at least one gateway is operational; up_status=0 means all gateways are down.
• Pass optional var2=1 to include performance status. When enabled, up_status=3 indicates that the option is available but has low success performance.
• The documented default hash uses sha512(key|command|var1|salt). When var2=1 is included, the documented request example uses sha512(key|command|var1|var2|salt).
• The current contract shows getNetbankingStatus as the command value for this endpoint. Recalculate the hash whenever var1 or var2 changes.

Action required

Replace calls to Get Net Banking Status with the Get PG Up Status contract. Update the hash calculation to match the request fields, and treat up_status=3 as a distinct state only when performance status is requested.

Need to migrate

Migration is required for integrations that depend on Get Net Banking Status. The new API supports the existing health-check use case and adds payment-option filtering and optional performance status.

Related documentation

• Get PG Up Status API
• Net Banking Codes
• Wallet Codes

Summary

For seamless S2S flow 4, PayU can return the QR image directly instead of requiring the merchant to convert the intent URL. Set sendqrimage to base64 for a base64-encoded image or url for an image URL.

Why this matters

Merchants can display the returned QR without maintaining a separate intent-URL-to-QR conversion step.

Who is affected

• Merchants using seamless S2S flow 4 for UPI QR payments.
• Developers rendering QR images from payment responses.
• Existing flow-4 integrations that currently generate a QR from the returned intent data.

What's new

• sendqrimage=base64 returns the image under the documented qrImage.base64.value response path.
• sendqrimage=url returns the image URL under qrImage.url.value.
• If sendqrimage is not set, the existing intent string response is returned and the merchant can continue generating the QR.
• sendqrimage must be enabled in the merchant configuration before use.

Action required

Request enablement from your PayU account contact, then add the desired sendqrimage value to the flow-4 request and handle the corresponding response path. Retain the existing intent-string fallback unless your integration no longer needs it.

Need to migrate

No migration is required. This is backward-compatible when sendqrimage is not set; adopting the direct image response is optional and requires enablement.

Related documentation

• UPI QR Generation API
• UPI Intent Server-to-Server Integration

Summary

The supplied Devguide documents /_payment for AMEX and RuPay recurring-payment cancellation and requires 2FA. The supplied asset does not establish an API-routing change to mandate_revoke for AMEX.

Why this matters

Merchants can align their recurring-payment cancellation flow with the documented AMEX and RuPay endpoint and authentication requirements, without treating an unconfirmed routing change as a release requirement.

Who is affected

• Merchants supporting AMEX or RuPay recurring payments.
• Developers implementing card-mandate cancellation.
• Teams reviewing recurring-payment cancellation authentication and routing.

What's new

• The supplied Devguide documents the /_payment cancellation flow for AMEX and RuPay recurring payments.
• The documented AMEX and RuPay cancellation flow requires 2FA.
• A cancelled mandate cannot be restored; the customer must register a new mandate if another recurring registration is needed.

Action required

Review the /_payment cancellation request and 2FA requirements in the linked API flow before rollout. Any intended change to mandate_revoke routing for AMEX requires separate engineering confirmation before publication.

Need to migrate

No API-routing migration is established by the supplied asset. Do not change AMEX cancellation routing based on this changelog entry alone; confirm any intended mandate_revoke change with engineering before publishing or implementing it.

Related documentation

• Cancel the Recurring Payment for Cards
• Cancel Recurring Payments of AMEX and RuPay Cards