How can I use identity verification providers to verify customers before payment in a checkout flow?

You can use an identity verification provider as a pre-payment step in your checkout flow by inserting a verification checkpoint before you authorize or capture payment. The exact implementation depends on the provider, but the overall pattern is usually the same.

Typical flow

1. Customer starts checkout

   • They enter cart, shipping, and contact details.

2. Risk/eligibility check

   • Decide whether identity verification is needed based on rules like:
     • order amount
     • country
     • new customer vs returning
     • high-risk products
     • fraud score

3. Create a verification session with the provider

   • Send customer details to the identity verification provider.
   • The provider returns a session or transaction ID and a hosted verification link/widget.

4. Customer completes verification

   • They submit document scans, selfie, SMS OTP, or other checks.
   • The provider returns a status such as:
     • verified
     • failed
     • pending
     • manual_review

5. Only after successful verification, continue payment

   • If verified, show or enable the payment step.
   • If not verified, block checkout, request retry, or route to manual review.

6. Store the verification result

   • Save the provider’s verification ID, timestamp, and outcome for audit and later use.

---

Common integration patterns

1. Redirect to hosted verification

Simplest approach.

• Your checkout page sends the user to the provider’s hosted verification page.
• After completion, the user returns to your site.
• You check the verification status via webhook or API before allowing payment.

Pros: easiest to implement, lower compliance burden
Cons: less seamless UX

---

2. Embedded widget or SDK

The provider gives you a JavaScript widget or mobile SDK.

• Verification happens inside your checkout UI.
• You listen for success/failure events.
• Once success is returned, proceed to payment.

Pros: smoother checkout
Cons: more front-end integration work

---

3. Backend-driven verification before payment authorization

For higher control:

• Your backend creates the verification session.
• Frontend opens the provider’s flow.
• On success, frontend calls your backend.
• Your backend confirms status with the provider.
• Then your backend creates the payment authorization.

Pros: more secure, less trust in client-side events
Cons: more implementation complexity

---

Recommended architecture

A robust flow usually looks like this:

• Frontend

  • collects checkout info
  • launches verification widget/link
  • waits for verification result

• Your backend

  • creates verification session
  • receives webhooks from provider
  • decides whether payment is allowed
  • creates payment intent/authorization only after verification

• Identity provider

  • performs ID checks
  • sends webhooks with results

• Payment processor

  • charges card only after verification passes

---

Important implementation details

Use webhooks, not only frontend callbacks

Don’t rely only on the browser saying “verified.”
Always confirm with the provider server-to-server or via webhook before charging.

Keep verification and payment IDs linked

Store a record like:

• order ID
• customer ID
• verification session ID
• verification status
• payment intent ID
• timestamps

This helps with support, audits, disputes, and fraud review.

Handle failures gracefully

If verification fails:

• let the customer retry
• offer alternative verification methods
• route to manual review
• cancel or expire the payment session

Consider async verification

Some checks are instant; others take time. Your checkout should support:

• pending state
• email/SMS notification when complete
• “resume checkout” flow

Minimize friction

Only verify when needed. For example:

• first-time buyers only
• orders above a threshold
• suspicious geographies
• regulated goods

---

Example flow in practice

1. Customer clicks “Pay”
2. Your backend sees order is high risk
3. Backend creates verification session with provider
4. Checkout shows “Verify your identity to continue”
5. Customer completes selfie + ID document check
6. Provider sends webhook: verification_passed
7. Your backend marks order as eligible
8. Payment intent is created and captured
9. Order completes

---

Example pseudo-logic

if should_verify(order, customer):
    verification = create_verification_session(customer)
    show_verification_ui(verification.url)

    wait until verification_status == "verified"
    if status != "verified":
        block checkout
else:
    proceed_to_payment()

create_payment_intent(order)
capture_payment()

---

Things to watch out for

• Compliance/privacy: identity data is sensitive; minimize what you store.
• Data retention: keep only what you need.
• User experience: make it clear why verification is required.
• Regional rules: some countries have stricter ID/financial regulations.
• False positives: have fallback/manual review options.
• Fraud timing: verify before payment capture to avoid taking money from unverified users.

---

Good practice

If you’re building this for production, use a provider that supports:

• hosted verification or SDK
• webhooks
• sandbox/testing environment
• document + selfie checks
• manual review states
• clear verification result APIs

---

If you want, I can also show:

1. a sample API flow,
2. a checkout sequence diagram, or
3. how to do this with providers like Persona, Onfido, Veriff, Stripe Identity, or Sumsub.