Build an embedded app

This section is a blueprint for a complete embedded finance app built on Weavr. Instead of documenting one endpoint at a time, it walks through the app the way your customers experience it - screen by screen - and shows which SDK component renders each screen and which API endpoint sits behind it.

If you've read How Weavr works and shipped your first transaction, this is the next step: assembling those pieces into a coherent product that looks and feels like the apps our EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. ship.

New to Weavr?

Start with How Weavr works for the core concepts - customers, InstrumentsInstrument A financial product owned by an Identity. There are two types: Managed Accounts (stored-value accounts that hold balances and can receive wire transfers) and Managed Cards (prepaid cards - virtual or physical - used for purchases)., and Transactions - then come back here to see how they fit together in a real app.

What you'll build

Picture a typical EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. app - say, a spend-management app for businesses. Its customers log in, hold a balance, spend on cards, pay suppliersSupplier A trusted business or individual that receives payments from Buyers through payment runs. Suppliers can be stored in a trusted supplier list, and when marked as trusted, may allow Buyers to skip Strong Customer Authentication when executing payment runs to those suppliers., and save the payees they pay most often. Every one of those capabilities is something you assemble from Weavr building blocks:

• Logging in and verifying users - onboard and verify a customer, then authenticate the people who act on their behalf.
• Viewing and managing cards - issue cards, show sensitive details securely, and run the full card lifecycle.
• Making payments - move money between accounts, to other Weavr customers, and out to external banks.
• Managing trusted payees - let customers save recipients once and pay them again with fewer approval steps.
• Showing activity and statements - the read side: live account and card activity feeds, plus downloadable bank statements.

Logging in and verifying users

Onboard and verify customers, then authenticate users with password or passcode and step up for sensitive actions.

Build authentication

Viewing and managing cards

Issue virtual and physical cards, show the PAN, CVV, and PIN securely, and manage the card lifecycle.

Build card management

Making payments

Move funds between your customer's own instruments, to other Weavr customers, and out to external bank accounts.

Build payments

Managing trusted payees

Let customers save recipients once, verify them once, and reuse them across future payments.

Build trusted payees

Showing activity and statements

Present live account and card activity feeds, card payment timelines, and downloadable bank statements.

Build the views

How the pieces fit together

An embedded finance app on Weavr has three layers. Understanding the split is the key to the rest of this section, because every feature is built by combining all three.

┌─────────────────────────────────────────────────────────┐
│  Your app (client)                                        │
│  ─ Your own UI, screens, and navigation                   │
│  ─ Weavr SDK components for anything PCI- or SCA-sensitive │
│    (login, card details, KYC/KYB) rendered in a           │
│    tokenized iframe / native view                         │
└───────────────┬───────────────────────────────────────────┘
                │  tokens, never raw secrets
┌───────────────▼───────────────────────────────────────────┐
│  Your backend                                              │
│  ─ Holds your API key, orchestrates calls                  │
│  ─ Passes through end-user tokens from the SDK             │
└───────────────┬───────────────────────────────────────────┘
                │  api-key + end-user Auth Token
┌───────────────▼───────────────────────────────────────────┐
│  Weavr API                                                 │
│  ─ Regulated accounts, cards, and payments                 │
│  ─ Compliance, SCA, and settlement                         │
└───────────────────────────────────────────────────────────┘

• Your app owns the experience. You build the screens. Wherever a screen touches a password, a card number, or identity documents, you drop in a Weavr secure SDK component so the sensitive value is captured or displayed inside a sandboxed view and never enters your code.
• Your backend holds your secret API key and makes the API calls. When a call acts on behalf of a customer, it carries the end-user Auth Token that the SDK produced at login.
• The Weavr API does the regulated work - issuing instrumentsInstrument A financial product owned by an Identity. There are two types: Managed Accounts (stored-value accounts that hold balances and can receive wire transfers) and Managed Cards (prepaid cards - virtual or physical - used for purchases)., moving money, running compliance and Strong Customer Authentication.

The golden rule

Sensitive data - passwords, full card numbers, CVVsCVV Card Verification Value - the 3-digit security code printed on a payment card, used to authenticate card-not-present transactions. Weavr returns CVV in tokenized form on `GET /managed_cards/{id}` (with a stepped-up token); the value is only detokenized inside the SDK's secure CVV display component., KYCKYC Know Your Customer - the identity verification process for consumer identities. This process allows you to seamlessly and securely verify your user's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. documents - flows through Weavr SDK components as tokens, so it never touches your servers. This keeps you at the lowest level of PCI compliance. Everything else flows through your backend as ordinary API calls.

The tech stack, mapped

Each feature in this section combines an SDK component (in your client) with one or more API endpoints (from your backend). Here's the whole app at a glance:

Feature	SDK components (client)	API endpoints (backend)
Verify a customer	KYC / KYB components	POST /consumers, POST /corporates
Authenticate a user	Login components (password / passcode)	POST /login_with_password
Step up for sensitive actions	Login + OTP	Step-up authentication
Issue and show cards	Card components (PANPAN Primary Account Number - the long card number (typically 16 digits) printed or embossed on a payment card and used to identify the card on the payment network. Weavr never returns the raw PAN to your client; `GET /managed_cards/{id}` returns the PAN in tokenized form as `cardNumber`, and the value is only detokenized inside a Secure UI card-number component (a sandboxed iframe on the web, a secure native view on mobile)., CVVCVV Card Verification Value - the 3-digit security code printed on a payment card, used to authenticate card-not-present transactions. Weavr returns CVV in tokenized form on `GET /managed_cards/{id}` (with a stepped-up token); the value is only detokenized inside the SDK's secure CVV display component., PINPIN Personal Identification Number - the numeric code a cardholder enters to authorize chip-and-PIN purchases and ATM withdrawals. PIN is only present on physical managed cards. Weavr returns it tokenized on `GET /managed_cards/{id}` (with a stepped-up token), and the SDK detokenizes it inside a secure PIN display component.)	POST /managed_cards, GET /managed_cards/{id}
Manage the card lifecycle	Your own UI	Block, report, replace, remove
Make payments	Login + OTP for SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).	Transfers, Sends, Outgoing wire transfers
Manage trusted payees	Login + OTP for SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).	Trusted payees
Show activity and statements	Your own UI (reference app)	Transaction activity, Statements

The SDK ships for Web, iOS, Android, and React Native. Every feature page links to the matching component on all four platforms. Some capabilities - biometric login, push provisioningPush Provisioning A method that allows cardholders to add their card to a digital wallet (such as Apple Pay or Google Pay) directly from your app. The card details are securely tokenized and sent to the wallet provider, streamlining the process and enhancing the user experience compared to manual provisioning. This feature is currently in beta., push-notification step-up - are mobile-only; see the SDK capability matrix when you plan which platforms deliver which screens.

Before you start

You'll build against the sandbox, so make sure you have:

• A sandbox account and your credentials - see Open a sandbox account and Keys and IDs.
• Your API key, Program ID, and the profileProfile A template defining the configuration for one type of object - corporate identity, consumer identity, managed account, managed card, transfer, or outgoing wire transfer. When you create one of these objects you reference its Profile ID, which tells Weavr which limits, currencies, supported countries, branding, and fees to apply. Your programme ships with one or more Profile IDs per supported object type. IDs for the instrumentsInstrument A financial product owned by an Identity. There are two types: Managed Accounts (stored-value accounts that hold balances and can receive wire transfers) and Managed Cards (prepaid cards - virtual or physical - used for purchases). you'll create (managed accountsManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr., cards, transfers, and outgoing wire transfersWire Transfer A transaction that moves funds between accounts. An incoming wire transfer moves funds from a third-party bank account to a Weavr managed account, while an outgoing wire transfer moves funds from a Weavr managed account to a third-party bank account. Wire transfers require the managed account to have an assigned IBAN (for EUR) or sort code and account number (for GBP).).
• The SDK set up in your client for at least one platform - start with the Web get-started guide.
• The Simulator to fund accounts, approve KYCKYC Know Your Customer - the identity verification process for consumer identities. This process allows you to seamlessly and securely verify your user's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers./KYBKYB Know Your Business - the identity verification process for corporate identities. This process allows you to seamlessly and securely verify your business customer's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers., and complete SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics). challenges without real money or real devices.

When you're ready, start with Logging in and verifying users - every other feature depends on having a verified customer and an authenticated user.