Showing your own confirmation after verification

When an energy consumer verifies successfully, the SDK shows a brief confirmation of its own inside the embedded frame. We recommend closing the flow at that point and showing a confirmation page you build yourself.

This applies to any integration — a web front end or a mobile app.

Why build your own

The SDK's confirmation is deliberately minimal. It renders inside the iframe, so it carries the SDK's layout rather than your product's, and it can say nothing about what happens next in your journey — which is the question the consumer actually has at that moment.

A page you control lets you:

Use your own design. Your type, spacing and colours, rather than the
embedded flow styled through theme.

Explain your next step. "We'll start collecting your readings within 24
hours" means something to your customer; the SDK cannot know it.

Keep the journey coherent. Verification is one step in your onboarding,
not a separate product, and it should not look like one.

Sequence what follows. Consent capture, terms, device setup — those are
yours to order.

This is a recommendation, not a requirement. If the SDK's own confirmation suits your journey, handle GLOW_IDV_EXIT and continue from there instead.

When to show it

As soon as the credential is issued.

Web

GLOW_IDV_SUCCESS carries the credential. Take it, tear down the flow, and render your page.

React Native

const result = await presentVerification({ subject: email });

if (result.status === 'verified') {
  navigation.navigate('VerificationSuccess', { result });
}

Or, using GlowIdvView directly, from onVerified.

Do not tear down on failure

A failed verification is recoverable — the SDK shows its own error and lets the consumer correct their details. Close the flow only on success; leave it in place so they can try again without restarting.

What to put on it

Everything below is already in the success payload, so no extra call is needed.

Element	Field	Why
Clear confirmation	—	State plainly that verification succeeded
What happens next	your product	The consumer's actual question
Meter point	`mpan`	Confirms which supply was verified
Method used	`method`	Render it readably, not as the raw value
Valid until	`token`	Decode the JWT's `exp` claim
Reference	`verificationId`	Useful if they contact support

The field names are the same either way. On the web they arrive on the message:

In React Native they arrive on the result:

const { token, mpan, method, verificationId } = result;

Render method in your own words rather than passing it through:

What not to put on it

Never display the credential

The token is a signed JWT whose payload contains the identifier you supplied as subject — often an email address. Do not render it, and do not put it anywhere it could reach a screenshot, a screen recording, a support ticket or an analytics event.

The consumer has no use for the credential. It goes to your server for consent capture and nothing else.

Example

Web

React Native

export function VerificationSuccessScreen({ result, onContinue }) {
  return (
    <ScrollView>
      <SuccessBadge />
      <Heading>You're verified</Heading>
      <Text>
        We've confirmed you live at this property. Next you'll review the terms,
        then set up your device.
      </Text>

      <Card>
        <Detail label="Meter point" value={result.mpan} />
        <Detail label="Method" value={describeMethod(result.method)} />
        <Detail label="Valid until" value={expiryOf(result.token) ?? '—'} />
        <Detail label="Reference" value={result.verificationId} />
      </Card>

      <Button title="Continue" onPress={onContinue} />
    </ScrollView>
  );
}

Reading the expiry

The credential is valid for three months. To show that date, read the exp claim from the JWT. This works unchanged in both browsers and React Native.

JWTs use base64url, which atob does not accept directly — the alphabet differs and the padding is stripped. Convert before decoding, or the date silently never appears.

Read only the claim you need. The same payload carries the identifier the consumer was verified against.

Optional: letting them keep a copy

Some journeys offer the credential as a record. If you do, make it a deliberate action — a button, never something the page does on its own — and hand it to the platform rather than rendering it.

Web

React Native

<Button
  title="Save credential"
  onPress={() => Share.share({ title: 'Glow verifiable credential', message: token })}
/>

This puts a sensitive credential wherever the consumer chooses to send it. Most journeys should omit it: the credential has already gone to your server, and they have no use for their own copy.

After the confirmation

Continue to consent capture. Verification alone does not grant access to smart meter data — the credential must be attached to the Consent Capture & Onboarding call, which your server makes.

Verification Result Screen

Showing your own confirmation after verification#

Why build your own#

When to show it#

Web#

React Native#

What to put on it#

What not to put on it#

Example#

Web#

React Native#

Reading the expiry#

Optional: letting them keep a copy#

After the confirmation#

Showing your own confirmation after verification

Why build your own

When to show it

Web

React Native

What to put on it

What not to put on it

Example

Web

React Native

Reading the expiry

Optional: letting them keep a copy

After the confirmation