---
title: 'Payment Returns and Payment Updates'
url: 'https://manuals.remository.com/payage-dev/receiving-payments/payment-returns-and-payment-updates'
markdown: 'https://manuals.remository.com/payage-dev/receiving-payments/payment-returns-and-payment-updates.md'
date: '2026-11-14'
description: 'A payment return occurs when payment is completed at the payment gateway and the gateway redirects back to your site or closes its iframe window. A payment update may occur later, for example if the payment is refunded or reversed at the gateway. Applications should handle both returns and updates,…'
taxonomy:
  category:
    - docs
---

[](#) [ edit this page](https://github.com/getgrav/grav-skeleton-rtfm-site/blob/develop/pages/04.receiving-payments/05.payment-returns-and-payment-updates/docs.md) 

# Payment Returns and Payment Updates

A payment return occurs when payment is completed at the payment gateway and the gateway redirects back to your site or closes its iframe window.

A payment update may occur later, for example if the payment is refunded or reversed at the gateway.

Applications should handle both returns and updates, and you should be aware of the following issues.

Some (but not all) gateways send a payment update to notify the original payment. Usually, this initial update notification will arrive after the return, but not always. Some gateways (notably Mollie and occasionally PayPal Standard) can send the update before the return. You must not assume that the return will occur before an update. An occasional problem with PayPal Standard is that the return never occurs at all - for example if the user closes the tab or browser before the redirect occurs. So it's very important for applications to be able to handle returns and updates in either order, and yet only register a single sale, and if applicable, only send a single email to the customer. You can use the PayageApi::set\_payment\_processed() call to achieve this.

## Payment Updates

Payment updates invoke Payage via the front end of the website. The source of an update request is the payment gateway, not the user's browser, so update requests do not include the Joomla session cookie, or any other Joomla cookies. Payment updates will fail if access to Payage requires a Joomla login.

A gateway update request typically looks something like this:

```
<site>index.php?option=com_payage&tmpl=component&format=raw&task=notify&aid=1012&tid=xxxxx
```

The URL parameters 'option', 'tmpl', and 'format' are standard Joomla parameters. Payage addons may add various other URL parameters in order to retrieve and process the update transaction. If any of these parameters are blocked by .htaccess rules or a third party extension, the update requests will fail.

Once Payage completes its own update processing, it invokes the application that originated the payment by including the file specified as "app\_update\_path" and calling the payment\_update() function. Note that even though the payment\_update() function is part of your application, the current component is Payage, and JPATH\_COMPONENT is the path of Payage, not your application. Also note that the Joomla getModel() method will search the Payage model directory before any directories specified by addModelPath().

 [ ](https://manuals.remository.com/payage-dev/receiving-payments/timeouts) [](https://manuals.remository.com/payage-dev/adding-a-new-gateway)

---

## Navigation

- Parent: [Receiving Payments](https://manuals.remository.com/payage-dev/receiving-payments.md)
- Previous: [Timeouts](https://manuals.remository.com/payage-dev/receiving-payments/timeouts.md)