Purpose declaration
Bind each request to the onboarding or compliance reason that requires the check.
PAN verification
Purpose-led PAN verification for eligible onboarding flows.
Validate PAN format and available partner-sourced identity context only where lawful, consented and necessary for business or merchant onboarding.
PayDrion
PAN review
Consent-led check
Illustrative product operating view
Purpose, consent and minimal result handling.
PayDrion operating record
PAN review
Requested
1
PAN format
2
Onboarding purpose
3
Consent
4
Match status
Evidence boundary
Consent-led check
Requested
Matched or reviewed
Evidence stored
PAN verification
Identity data should be used only for the documented onboarding need.
PayDrion exposes necessary status signals, minimises retained fields and routes mismatch or unavailable results for review.
Minimal response use
Use only the match and status fields needed for the documented decision.
Reviewable exceptions
Route mismatch, unavailable and inconsistent results for human review instead of silent rejection.
PAN verification
PAN verificationDedicated product layer · shared PayDrion evidence model
Identity data should be used only for the documented onboarding need.
PayDrion exposes necessary status signals, minimises retained fields and routes mismatch or unavailable results for review.
PAN verificationDedicated product layer · shared PayDrion evidence model
PayDrion product architecture
Consent-led check
PAN format
Bind each request to the onboarding or compliance reason that requires the check.
Requested
Onboarding purpose
Use only the match and status fields needed for the documented decision.
Matched or reviewed
Consent
Route mismatch, unavailable and inconsistent results for human review instead of silent rejection.
Evidence stored
Match status
Bind each request to the onboarding or compliance reason that requires the check.
Requested
PayDrion evidence lineRequest · decision · partner reference · signed event · operator action
Programme boundary
API availability does not equal permission to operate the underlying regulated service.
Activation requires an eligible business model, authorised partner structure, documented operating responsibilities and applicable customer-protection controls.
Where it fits
Designed around the job the money movement must complete.
Configuration follows the real transaction purpose, customer experience and operating responsibility—not a one-size-fits-all product label.
01
Merchant KYB
02
Business onboarding
03
Compliance review
Questions
Practical answers before implementation.
Commercial and technical details are confirmed for the specific entity, use case and approved programme.
How does implementation begin?+
PayDrion first maps your business model, transaction flow, expected volumes, risk profile and required payment rails. An implementation plan and test credentials follow successful onboarding.
Can this be enabled for every business?+
Availability, limits, pricing and settlement timelines depend on onboarding, use case, bank or network partner approval, and applicable regulation.
How are transaction states confirmed?+
Use the synchronous API response for immediate context, then rely on signed webhooks and server-side status verification as the operational source of truth.