Skip to main content

Making payments

Moving money is the point of an embedded finance app. This page builds the payment flows: shifting funds between a customer's own 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)., paying another Weavr customer, and sending money out to an external bank - each with the right Strong Customer Authentication step.

Where this fits

This page assumes you've built authentication and that the customer holds a funded managed account. Payments move real value, so most carry an 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). step - the same step-up you built earlier.

Here's the payment review screen you'll build. It's your own UI, driven end to end by API calls - each 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. shows the endpoint behind it:

your app

Review payment

To an external bank

£2,500.00To Acme Ltd · GB29 NWBK 6016 1331 9268 19
API · data sourcePOST/outgoing_wire_transfersAmount and destinationYour own UI collects the amount and payee; your backend creates the outgoing wire transfer in PENDING_CONFIRMATION.View docs →
API · data sourcePOST/outgoing_wire_transfersPayee name checkWeavr runs Confirmation of Payee (GBP) or Verification of Payee (EUR) before the money leaves. Show the result so the user can confirm or cancel.View docs →
Confirm & pay
API · data sourcePOST/outgoing_wire_transfers/{id}/confirmConfirm & payConfirmation is a Strong Customer Authentication step - step up the user's token, then confirm the transfer.View docs →
SDK component (renders the area)API endpoint (the data source)

Hover or focus a numbered pin to see which Weavr secure component renders the area, or which API endpoint supplies its data - then click to open the docs.

Step 1: Pick the right transaction type​

A transaction is a movement of funds between instruments. Which one you use depends on where the money is going:

User intent in your appTransaction typeMoves money
Move funds between my own 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).TransferBetween two of the same customer's 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).
Pay another Weavr customerSendFrom your customer to another Weavr customer
Pay an external bank accountOutgoing wire transferFrom a managed accountManaged 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. out to a third-party bank
Spend on a cardCard paymentFrom a card at a merchant (handled by the scheme)

Card spending is driven by the cardholder at a merchant - you don't initiate it - so your app mostly retrieves and displays those. The three you initiate are transfers, sends, 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)..

Step 2: Move money internally with transfers​

The simplest payment is a transfer - money between two 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). the same customer owns, for example topping a prepaid card up from a managed accountManaged 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.. Transfers stay inside Weavr, so they settle instantly.

POST/transfersTry it 
{
  "profileId": "string",
  "tag": "string",
  "source": {
    "id": "string",
    "type": "managed_cards"
  },
  "description": "string",
  "destination": {
    "id": "string",
    "type": "managed_cards"
  },
  "destinationAmount": {
    "currency": "str",
    "amount": 0
  },
  "scheduledTimestamp": "string"
}

Step 3: Pay another Weavr customer with a send​

A send moves funds from your customer's instrumentInstrument 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). to another customer on the same Weavr program. Because a send can leave your customer's control, it's subject to Strong Customer Authentication unless the destination is a trusted payee.

POST/sendsTry it 
{
  "profileId": "string",
  "tag": "string",
  "source": {
    "id": "string",
    "type": "managed_cards"
  },
  "destination": {
    "id": "string",
    "type": "managed_cards"
  },
  "destinationAmount": {
    "currency": "str",
    "amount": 0
  },
  "description": "string",
  "scheduledTimestamp": "string"
}

Step 4: Pay an external bank with an outgoing wire transfer​

An outgoing wire transfer (OWT) sends funds from a managed accountManaged 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. to a bank account at another institution. This is the flow with the most moving parts, so build it carefully.

Before a customer can send one, they need a managed account with an assigned IBAN and an enrolled device 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)..

Create the transfer​

POST/outgoing_wire_transfersTry it 
{
  "profileId": "string",
  "tag": "string",
  "sourceInstrument": {
    "type": "managed_accounts",
    "id": "string"
  },
  "transferAmount": {
    "currency": "str",
    "amount": 0
  },
  "description": "string",
  "destinationBeneficiary": {
    "name": "string",
    "type": "PERSONAL",
    "address": "string",
    "bankName": "string",
    "bankAddress": "string",
    "bankCountry": "st",
    "bankAccountDetails": {
      "iban": "stringstringstr",
      "bankIdentifierCode": "stringst"
    },
    "nationality": "st",
    "dateOfBirth": "2019-08-24"
  },
  "scheduledTimestamp": "string"
}

Show the payee verification result​

Weavr runs an automatic payee name check before the money leaves. The transfer is created in PENDING_CONFIRMATION, and your app must show the result to the user so they can confirm or cancel:

  • GBP via Faster PaymentsFaster Payments The UK domestic real-time payment scheme (run by Pay.UK) used to clear GBP wire transfers between UK bank accounts in seconds. GBP managed accounts settle incoming and outgoing wire transfers via Faster Payments, and our [Confirmation of Payee](/transactions/owt/cop/overview) checks run over this scheme. uses Confirmation of Payee (CoP) - returns Match, Close Match, or No Match, with reason codes.
  • EUR via SEPASEPA Single Euro Payments Area - the European scheme that standardises euro-denominated bank transfers across participating countries. EUR managed accounts settle incoming and outgoing wire transfers via SEPA Credit Transfer (SCT) or SEPA Instant; our [Verification of Payee](/transactions/owt/vop/overview) check runs against the IBAN registered with the beneficiary's bank or PSP before a SEPA payment executes. uses Verification of Payee (VoP) - returns Match, Close Match, No Match, or Not Possible.

The VoP result screen gives ready-made UI patterns for presenting these outcomes.

Confirm with Strong Customer Authentication​

Once the user reviews the payee result, they confirm the transfer. Confirmation is an 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). step - step up the user's token, then confirm:

POST/outgoing_wire_transfers/{id}/confirmTry it 
{
  "id": "string",
  "profileId": "string",
  "tag": "string",
  "sourceInstrument": {
    "type": "managed_accounts",
    "id": "string"
  },
  "transferAmount": {
    "currency": "str",
    "amount": 0
  },
  "description": "string",
  "type": "SEPA",
  "destination": {
    "name": "string",
    "type": "PERSONAL",
    "address": "string",
    "bankName": "string",
    "bankAddress": "string",
    "bankCountry": "st",
    "bankAccountDetails": {
      "iban": "stringstringstr",
      "bankIdentifierCode": "stringst"
    },
    "nationality": "st",
    "dateOfBirth": "2019-08-24"
  },
  "state": "INVALID",
  "rejectedInfo": "SYSTEM",
  "challengeExemptionReason": "LOW_VALUE",
  "creationTimestamp": 0,
  "scheduledTimestamp": "string",
  "executionTimestamp": "string",
  "cancellationReason": "string",
  "validationOutcomes": [
    {
      "category": "UK_CONFIRMATION_OF_PAYEE",
      "categoryResult": {
        "match": "EXACT_MATCH",
        "reasonCode": "ANNM",
        "accountName": "string"
      }
    }
  ]
}

See confirm transactions for how confirmation and step-up fit together across transaction types.

Skip the extra approval with trusted payees

If the destination is a saved trusted payee, an OWTOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication. or send can skip Strong Customer Authentication and execute automatically - fewer taps for your customer on recurring payments. That's the next page.

Step 5: Test in the sandbox​

Move money without real funds using the Simulator: fund an account, settle transfers, and trigger specific OWTOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication. outcomes - including CoP and VoP match results - with the OWT sandbox testing helpers. Subscribe to the outgoing wire transfer and transaction activity events so your app reflects each state change.

What you've built​

Your app can now move money three ways - internally, to other Weavr customers, and out to external banks - with payee verification and 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). where the regulations require them.

Next, cut the friction on repeat payments: managing trusted payees.