Identifier validation
Recognize the account format and collect the payee or account-holder details required for that route.
Integration story · Payment verification
One account-verification interface across fragmented payment schemes.
Before funds move, a business may need to check whether the supplied payee name aligns with the destination account. The challenge is that identifiers, routing rules, supported checks and response formats vary by country and scheme.
INTEGRATIONBanficoPayment verification
Payee-name matching
Multi-scheme routing
Common API interface
The integration requirement
Normalize the request without weakening the local verification check.
Account identifiers are not globally uniform. IBAN and non-IBAN flows can require different input structures, and local schemes may expose different combinations of name-match and account-status signals.
A usable integration therefore needs a common request model, scheme-aware routing and an explicit response that distinguishes supported checks, partial results and unavailable signals. A single endpoint should simplify access without pretending every rail behaves the same way.
What the integration demands
Four controls behind reliable payee verification.
The interface must preserve the meaning of each local scheme while keeping the calling workflow consistent.
Scheme-aware routing
Direct each supported request to the appropriate verification rail without hard-coding local logic upstream.
Response normalization
Translate available name-match and account-status signals into a consistent response model.
Explicit exceptions
Expose unsupported markets, missing inputs and incomplete responses instead of returning false certainty.
From payment detail to verification response
A controlled route from supplied payee data to a scheme-backed result.
- 01Receive
Accept the payee name, account identifier and any additional holder details required.
- 02Validate
Check that the request is complete and identify the applicable market and account format.
- 03Route
Send the supported request through the appropriate account-verification scheme.
- 04Return
Provide the available name-match or status result with exceptions kept visible.
The operating model
Local verification logic behind a consistent enterprise response.
The integration pattern lets a payment or onboarding workflow call one interface while preserving the differences between account formats, scheme coverage and returned signals. The result is easier to use precisely because unsupported or incomplete checks remain explicit.
Payee and account inputs handled consistently Requests routed according to local scheme rules Match and status signals normalized Coverage gaps and exceptions kept visible
Integration-story disclosure
This public summary describes the account-verification integration requirement and relevant service categories. It does not claim a completed production rollout or disclose customer-specific coverage, networks, technical architecture, service levels, dates, outcomes, agreement status, pricing or other confidential terms.
Payment verification