Skip to main content
Every Rain product acts on a customer record. Get the identity model right once and the rest of the platform follows, because the same records carry across cards, accounts, and money movement.

​
The four levels

Rain’s identity model has four levels. Which ones you use depends on your program type: Your program type decides whether you start from a company or a user. Consumer programs create users directly. Corporate programs create a company first, and the corporate application also creates that company’s first user. See Flow of funds for what else the choice affects.

​
Authorized users

An authorized user is an additional person you attach to an existing customer, for example a second cardholder on a company account. Authorized users are enabled per program; contact Rain if your program needs them.

​
One record, several products

A user or company is not a cards object. It’s a platform object that every product references. The same userId or companyId you use to issue a card is the identifier you pass when you create a payment route to move money, and the ledger opens one account per user or company regardless of which products they use. That’s what makes adding a second product cheap: no second customer directory, no reconciliation between two views of the same person.
Sharing a record is not sharing an approval. Cards KYC or KYB and payments verification are separate gates, and clearing one does not clear the other. Check the relevant status before you act. See Payments compliance.

​
Mapping Rain records to your own

Rain identifies customers by UUID, but you probably already have your own identifier for the same person. Set externalId to carry it, and you can look customers up by your identifier instead of storing a mapping table. externalId is a string of up to 255 characters that must be unique within your tenant. You can set it when you create a customer or an application, and change it later: Once it’s set, four lookups accept your identifier in place of Rain’s:
externalId must be unique within your tenant. Reusing a value that already belongs to another customer fails, so derive it from a stable primary key in your own system rather than from something a customer can change.

​
What’s next

See the platform architecture

Where customer records sit relative to compliance, products, and the ledger.

Understand the flow of funds

Consumer or corporate, Rain-managed or partner-managed.

Read how compliance works

What each verification pipeline unlocks for a customer record.

Onboard a cardholder

Submit an application and take a customer through verification.