> ## Documentation Index
> Fetch the complete documentation index at: https://developer.moneyone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# User Redirection

> Redirect the customer to the combined consent screen and handle the return.

After [Initiate Consent](./initiate-consent), redirect the customer to the
`orchestrationWebUrl` returned in the response. The customer completes the entire
consent journey — across every FIU named in the request — on one combined screen.

## Redirect the customer

Redirect the customer's browser to `orchestrationWebUrl`. If you didn't supply
`customer.fipIds` on Consent Creation, they first see a combined FIP-selection
screen; either way, they approve (or reject) consent for every named FIU on one
combined screen — fully hosted by MoneyOne. You do not need to build or manage any
part of this UI, and you never see or handle the underlying Account Aggregator
redirect URL directly.

## Return to your app

Once the customer finishes, MoneyOne redirects their browser to the `redirectUrl` you
supplied on Consent Creation, if any.

<Note>
  This redirect is a UI signal only — it tells you the customer finished the consent
  flow, not the terminal outcome of each consent. Confirm the actual outcome via the
  consolidated consent callback below, or [Track Status](./track-status).
</Note>

## Consolidated consent callback

Rather than one notification per FIU, you receive **one consolidated callback per
Consent Creation call**, covering every FIU named in that request. You need a webhook
URL configured to receive it — provide this at onboarding; MoneyOne's team configures
it for you.

This fires within a maximum of **120 seconds** after the customer's browser is
redirected back to your `redirectUrl`.

<Note>
  Use this webhook as your primary signal, and [Track Status](./track-status) —
  passing `transactionId` alone — as a complement, not just a fallback for when the
  webhook fails to arrive.
</Note>

### Payload shape

```jsonc theme={null}
{
  "timestamp": "2026-03-31T08:02:45.111480334Z",
  "transactionID": "ad277c38-ca13-49b0-befd-38343e221e6b",  // the same transactionId returned by Consent Creation
  "eventType": "JOURNEY_COMPLETE",
  "eventStatus": "SUCCESS",       // SUCCESS or FAILED for the overall callback mechanism — not any individual consent's outcome
  "eventData": [
    {
      "type": "AA",
      "status": "SUCCESS",
      "consents": [
        {
          "consentID": "6934dcbb-ee3f-4ea0-85dc-b564c9e5e1d2",   // null if this consent's outcome is CONSENT_REJECTED
          "consentHandle": "7af9f26a-097c-4974-9e63-164a2b4c598e",
          "consentStatus": "CONSENT_APPROVED",                    // or CONSENT_REJECTED
          "fiuId": "string",     // which of your onboarded FIUs this consent belongs to — per-consent, since one callback can cover several FIUs at once
          "productID": "string",
          "fetchType": "PERIODIC",
          "fiFetch": "MANUAL"    // MANUAL or AUTOMATIC — a per-product configuration setting, not something you set per call
        }
        // ...one entry per consent covered by this transaction
      ]
    }
  ]
}
```

This callback carries consent-level detail only — no `accounts`/`dataFetchStatus` field. Account and
data-fetch detail is reported separately, per FIU, once a fetch actually runs — via the
[data-fetch webhook](./request-data#data-fetch-webhook) or via [Track Status](./track-status), which
already exposes the accounts approved at consent time independently of this callback.

### Payload fields

| Field                  | Description                                                                                                                                       |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `timestamp`            | ISO-8601 time the event was emitted.                                                                                                              |
| `transactionID`        | The `transactionId` returned by Consent Creation.                                                                                                 |
| `eventType`            | Always `JOURNEY_COMPLETE`.                                                                                                                        |
| `eventStatus`          | `SUCCESS` or `FAILED` — describes the callback mechanism itself, not any individual consent's outcome. Read `consentStatus` per consent for that. |
| `eventData`            | Array of result blocks. Contains a single `AA` block.                                                                                             |
| `eventData[].consents` | One entry per consent covered by this transaction, potentially spanning multiple FIUs.                                                            |

<Note>
  If some FIUs are still not terminal after this callback arrives, poll
  [Track Status](./track-status) up to 5 times, 5 seconds apart, before treating the
  remainder as failed.
</Note>

## Next step

Track each consent to a terminal state, or confirm the outcomes above, via
[Track Status](./track-status).