Skip to content
NexusBook a demo

Financial services use case · Stripe + Salesforce + OpenAI + ServiceNow

Merchant onboarding verification

The merchant's stated activity, ownership documents and payment-account setup are reviewed separately from the decision that allows transactions. Merchant risk owners receive business and ownership evidence before approved activation reaches the payment platform.

Discuss this use case Financial services overview

Systems involved

What each system contributes

Stripe

43 actions

  • Core Resources16
  • Products8

Trigger source: Stripe

Salesforce

73 actions

  • Accounts10
  • Contacts10
  • Cases12

Trigger source: Salesforce (SOQL polling)

OpenAI

25 actions

  • Chat Completions8
  • Files4
ServiceNow

55 actions

  • Tickets10

Trigger source: ServiceNow

Connecting Stripe does not provide the KYC and screening workflow. Identity, ownership and screening systems are separate authorized interfaces, and payment-platform operations depend on the account model and available permissions. Core banking, lending, policy administration, claims, identity verification, KYC and sanctions screening have no pre-built Nexus connector. They are reached through the institution's approved APIs, database access or vendor interfaces, or as Rules + Code, inside the same workflow and with the same approvals and audit.

Architecture

One governed run

Trigger: Salesforce applicationIntegration: Stripe + ServiceNowInterface: identity, ownership and screeningRules + CodeAI step: model of your choiceHuman ApprovalSystem Action: StripeAudit

How it starts: A merchant application is released from Salesforce for the payment service provider's verification process.

Step by step

How the process runs

  1. 01

    Establish the application

    Read the Salesforce merchant context, link the available Stripe account or payment-platform reference and open the ServiceNow review case.

  2. 02

    Gather verification evidence

    Call the authorized identity, ownership, KYC and screening interfaces for the required business evidence and result references.

  3. 03

    Apply acceptance rules

    Evaluate complete and verified fields against the institution's versioned acceptance and referral conditions without activating the merchant.

  4. 04

    Compare the business activity

    The selected model reviews the stated activity against the permitted submitted evidence and presents source-linked mismatches or questions for the risk owner.

  5. 05

    Decide and activate

    After the named risk owner approves, a separate authorized payment-platform interface applies the permitted activation or capability change and records the resulting state.

Control

Human decision and exception path

Human decision

The named merchant risk owner approves the onboarding outcome and the specific capability or activation scope before the account can transact through that authorization. A payment provider's own acceptance requirements remain separate from the institution's internal approval.

Exception path

  • Incomplete ownership or verification results keep the application pending without assuming clearance.
  • A changed activity description or ownership record returns the affected review to the risk owner.
  • An approved activation request without destination confirmation remains unresolved until the platform state is reconciled.

Evidence

What gets audited

  • Merchant application version and platform-account reference.
  • Verification results, acceptance-rule version and model comparison.
  • Risk-owner decision, authorized capabilities and timestamp.
  • Activation-interface response and confirmed platform state.

Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.

Sovereignty and deployment

Related

Patterns, connectors and next steps

FAQ

Questions about this use case

Does Nexus replace any of these systems?
No. Each system keeps its own records. Nexus runs the process between them and records each decision.
How does the run start?
A merchant application is released from Salesforce for the payment service provider's verification process.
What if a step is not covered by a pre-built action?
Connecting Stripe does not provide the KYC and screening workflow. Identity, ownership and screening systems are separate authorized interfaces, and payment-platform operations depend on the account model and available permissions. Core banking, lending, policy administration, claims, identity verification, KYC and sanctions screening have no pre-built Nexus connector. They are reached through the institution's approved APIs, database access or vendor interfaces, or as Rules + Code, inside the same workflow and with the same approvals and audit.
Is internal approval enough to guarantee a merchant can transact?
No; the workflow also checks the actual platform capability state and any outstanding provider requirements before recording activation as complete.

Use case review

Discuss this use case

Bring your version of the process. We will map the systems, approvals and evidence it needs.

Discuss this use case Book a demo