Integration points

Adding credential verification to a product means connecting a small number of things you already own to a MATTR surface. This page maps those connections for each verification channel: what you connect, who owns each side, and which MATTR VII or MATTR Pi surface implements it.

This page covers what connects to what. To choose a channel in the first place, start with the Verification overview. To see the messages that travel between components, see the workflow page for your channel.

The integration boundaryCopy Anchor Link

The channel you choose decides where verification actually runs, and that in turn decides what you have to operate. This is the single most useful thing to settle before you design anything else.

Integration points at a glanceCopy Anchor Link

In-person verificationCopy Anchor Link

In-person verification runs entirely on the verifier's device, so the boundary sits inside your own app rather than between your systems and a MATTR service. Your integration points are:

• The Verifier Mobile SDK in your app. You own the user interface, the operator workflow, and what happens after a result comes back. The SDK owns device engagement over QR or NFC, the Bluetooth Low Energy session, and the cryptographic checks. See In-person verification.
• Verifier Application registration. Each app instance registers with your MATTR VII tenant and obtains a license through the SDK Backend, keyed by bundle identifier and team ID on iOS or package fingerprint on Android. See SDK Backend.
• The trusted issuer list on the device. Because this flow works offline, trust material has to be loaded and refreshed ahead of time. Plan the refresh cadence as part of your integration, not as an afterthought. See In-person trusted issuers.
• Device permissions. Bluetooth and NFC permissions belong to your app manifest and the operating system, not to the SDK.
• Your result store. Nothing persists results for you. See Handling verification results.

Revocation checking also has an offline consequence. See In-person revocation status check.

If you use MATTR GO Verify insteadCopy Anchor Link

MATTR GO Verify moves the boundary. MATTR owns the application, and you own branding, configuration, and the MATTR VII tenant behind it. There is no SDK integration and no app development, so the integration points reduce to tenant configuration, trust configuration, and app distribution.

Remote web verificationCopy Anchor Link

This is the most connection-dense channel. Your website calls the Verifier Web SDK, the SDK creates a presentation session on your MATTR VII tenant, and verification happens on the tenant rather than in the browser.

The integration points, in the order you meet them:

1. Front end invocation. Your web application calls requestCredentials(). See the Verifier Web SDK overview.
2. Session correlation. You supply a state value so you can tie the verification back to whatever the user was doing in your product. See Correlating verification sessions.
3. Request-time hook (optional). The SDK calls your onPresentationRequest function when the request is created and whenever it is regenerated, which is where audit and timer logic belongs. See Presentation request hook.
4. Wallet invocation. Redirect, QR code, or the Digital Credentials API, depending on whether the journey is same-device or cross-device. See OID4VP wallet interactions and DC API.
5. Result delivery. Either the front channel, where the result returns through the SDK, or the back channel, where your backend retrieves it from your tenant. Production implementations should use back channel delivery with a backend, because it validates the challenge and protects against session replay. That makes a backend an integration requirement rather than an option. See Handling verification results.
6. Branding (optional). You supply branding for the request web view. See Customizing the request web view.

For the message sequence behind these points, see the remote web verification workflow.

Remote mobile verificationCopy Anchor Link

Remote mobile verification starts from the Verifier Mobile SDK in your app, but the checks run on your MATTR VII tenant, as they do for remote web. Your integration points are:

• The Verifier Mobile SDK and Verifier Application registration. As for in person, the SDK owns the request, and your app owns the user interface and what happens after a result comes back.
• Trusted issuers on your tenant. As for remote web, the tenant enforces the trusted issuers you configure, not an on-device list. See Remote trusted issuers.
• Trusted wallet providers. You create a trusted wallet provider on your tenant for each Holder app you support. It defines the authorization endpoint, such as a custom URI scheme or a universal link, that your tenant returns to invoke that app. See create a trusted wallet provider.
• App-to-app invocation. Your app invokes a Holder app on the same device, so URL scheme handling and platform behavior become part of your integration. See the remote mobile workflow.
• Result retrieval. As with remote web, results come back through your tenant. See Handling verification results.
• Verify with Apple Wallet (iOS). This path depends on an entitlement Apple grants to your organization and a certificate held on your tenant. Treat the Apple approval as a lead time item in your plan. See Verify with Apple Wallet.

Trust and PKI across all channelsCopy Anchor Link

Two trust decisions cut across every channel, and both are integration points rather than settings.

Which issuers you accept. You decide the source. That can be a list you configure and maintain yourself, or a signed trust list published by an ecosystem operator through a Digital Trust Service. If you consume a VICAL, the refresh cadence and caching are yours to own. See Remote trusted issuers and VICAL consumption.

How Holder apps know to trust you. Holder apps authenticate the verifier before releasing data, so your verification requests are signed against a reader certificate chain. MATTR VII can manage that material, and an ecosystem operator can publish your reader root in a RICAL so wallets across the ecosystem recognize you. See Signing verification requests and RICAL consumption.

Downstream systemsCopy Anchor Link

Everything after the verification result is yours. MATTR VII returns the outcome, and result persistence, audit trails, case management, and any decision your business makes on the back of the result sit entirely on your side of the boundary.

There is no verification webhook today, so MATTR VII does not push verification events to you. Event access is through the Analytics API, which you poll. See Analytics.

Where verification sits in your product journey, as opposed to what you wire up, is covered separately in the identity verification integration patterns.

Related integration pointsCopy Anchor Link

• Issuance integration points for the issuer side.
• Holding integration points for the Holder app side of presentation.
• Digital Trust Service integration points for consuming and publishing ecosystem trust.
• Platform management integration points for tenant provisioning, access control, and observability.

Next stepsCopy Anchor Link

• Choose your channel from the Verification overview.
• Run the verification quickstart.
• Compare MATTR VII, MATTR Pi, and MATTR GO in Platforms.