The embedded consent approach allows your application to present more of the consent experience directly within your own user journey, while still using Wych for the underlying consent, connectivity and data access capabilities.

This approach gives you more control over the customer experience, branding and flow orchestration than a fully hosted consent journey.

Before you start

Before implementing an embedded consent journey, make sure you have:

• a configured Partner profile
• a registered application
• working access credentials
• a clear understanding of the consent scope your application needs
• a customer journey that explains what data is being requested and why
• the ability to manage redirects, state and post-consent handling in your application
• alignment with the relevant market and customer experience requirements

What embedded consent means

With embedded consent, your application owns more of the front-end journey shown to the customer.

Typically, your application will:

• introduce the purpose of the connection
• explain what data is being requested
• guide the customer into the consent flow
• handle redirects and return states
• resume the application journey once consent is complete

Wych still supports the underlying connection and consent capability, but your application is responsible for a greater share of the customer-facing experience.

When to use embedded consent

An embedded approach is usually best when you want to:

• keep the customer inside your own application experience as much as possible
• apply your own UX patterns and content design
• tailor the flow to a specific onboarding or servicing journey
• maintain tighter control of how and when consent is introduced

This approach is often more flexible, but it also requires more implementation effort and more attention to compliance and user experience detail.

What the customer needs to understand

Before a customer grants consent, they should clearly understand:

• who is requesting access
• what data is being requested
• why access is required
• how long the access will last
• how the data will be handled
• how consent can be withdrawn

Your embedded flow should make these points clear before the customer proceeds.

Typical embedded journey

A typical embedded consent flow looks like this:

1. your application explains the purpose of the connection
2. the customer chooses to continue
3. your application initiates the consent process
4. the customer is redirected or advanced into the relevant authentication and authorisation steps
5. the customer authenticates with the institution where required
6. the customer reviews and approves the consent
7. your application receives the return from the consent flow
8. your application resumes and begins data retrieval

Design and implementation considerations

When building an embedded consent journey, make sure you consider:

• clear customer language and disclosure
• preservation of state between steps
• error handling and recovery paths
• branding consistency
• support for expired, revoked or incomplete consent
• clear return behaviour after consent completes
• customer support paths if the journey fails

Your implementation should make it easy for the customer to understand what is happening at each step and what will happen next.

Compliance considerations

Because embedded consent gives you more control over the user journey, it also gives you more responsibility.

You should ensure your implementation aligns with the relevant requirements for your market, including any applicable customer experience standards, disclosure requirements and consent handling expectations.

This is especially important where the consent experience is regulated, or where there are expectations around wording, visibility, revocation and informed customer choice.

What to check after implementation

Once your embedded consent flow has been implemented, confirm that:

• customers can complete the journey successfully
• the requested data scope matches the intended use case
• the return journey behaves correctly
• consent status is available to your application
• follow-up API calls only occur after consent is active
• failed or abandoned journeys can be identified and handled

Common reasons to choose hosted instead

If you want to reduce build effort or move more quickly, the hosted consent journey may be a better fit.

Hosted consent is often the simpler choice when you want:

• faster implementation
• less front-end consent build work
• Wych-managed consent screens
• a more standardised connection journey

What this step enables

Once your embedded consent flow is working and the customer has successfully granted consent, your application can begin retrieving permitted data using the active connection.

Next step

Continue to Retrieve data to call the relevant Recipient APIs using the active consent.