Weavr platform updates

New Statements and Transaction Activity endpoints, the card payments object, incoming wire transferWire 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). endpoints, payment confirmation, and a terminology refresh.

Statements and Transaction Activity

We've reworked how transaction data is exposed. The current statement endpoint serves many purposes at once: a historical record, a live feed, a durable document, and a metadata source, which makes it hard to integrate against. We've split it into two separate concerns and released two new endpoints, as well as adding a single object for the card payment lifecycle, and filled a gap on incoming 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)..

Statements — the authoritative, immutable statement of record for an 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). over a period.

• Settled activity only, with Weavr-computed opening and closing balances, so there's no need for balance reconstruction from other sources.
• Immutable: the same period always returns the same result.
• Available per 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. and per managed cardManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User..
• Available as JSON, PDF, and CSV. The PDF is our out-of-the-box durable-format statement, ready to be shared directly with end-customers.
• Transaction data is arranged by type, with first-class counterparty, forex, and fee objects replacing the old, overloaded additionalFields object. Fees are also first-class entries.

Non-breaking migration — today's behaviour stays the default; opt in to the new behaviour with the x-api-version: LATEST header. The previous behaviour is deprecated but remains available, and is the default unless you specify LATEST. We also provide an open-source UI reference implementation, including a sample PDF.

See the statements documentation.

Transaction Activity — a live, unified feed of everything happening on an 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)..

• All activity, pending and settled; unlike statements, it includes in-flight transactions.
• A single normalized shape across every transaction type, with common top-level information and the full type-specific object available underneath.
• Query the unified feed (GET /transactions) or scope it to a single 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. or card.
• The data returned matches what's delivered by webhook, so there are no channel-specific gaps.
• A UI reference implementation, with Account Activity and Card Activity views, is provided.

See the transaction activity documentation.

Card payments — the full lifecycle of a card payment is now a single object.

• The authorisation, settlement(s), and any reversal, refund, or original credit are grouped under one card payment id, with an ordered event timeline.
• New endpoints: GET /card_payments, GET /card_payments/{id}, and GET /card_payment_events.
• A completed card payment appears as one line in a statement and as a single record in the transaction history, with the full event history also available through transaction activity.

See the card payments documentation.

Incoming wire transferWire 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). endpoints — added GET /incoming_wire_transfers (and retrieve-by-id) for consistency with the other transaction types; you can now query received wires directly.

See the incoming wire transfers documentation.

Payment confirmation

A new endpoint retrieves a customer-facing PDF confirming an outgoing wire transferWire 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). has been sent: GET /outgoing_wire_transfers/{id}/payment_confirmation.

The confirmation states that the funds were sent via the instructed payment rail. It is not a confirmation that funds have arrived, because settlement times vary depending on the network and the receiving bank.

It is available once the outgoing wire transferWire 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). reaches COMPLETED. Watch the outgoing wire transferWire 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). webhook for the COMPLETED transition, then make the confirmation available to your end customer, for example via a download button in your app.

See the payment confirmation documentation.

Terminology change and API spec reorganization

We've aligned our terminology to better reflect how 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. use and understand our product in relation to their embedded finance programmeProgramme A programme represents your application within Weavr. Everything you create - Identities, Instruments, Transactions - sits beneath a Programme. When you register as an Embedder, you receive a Programme in the Sandbox and, once approved, one in Production., and reflected it in the API specification as well.

• Identities are now customers. The underlying entities are still corporatesCorporates Business entities that can be onboarded as identities on Weavr. Corporate identities represent companies and require Know Your Business (KYB) verification. They can have multiple authorised users and issue cards to card assignees. and consumersConsumers Individual persons who can be onboarded as identities on Weavr. Consumer identities represent individual customers and require Know Your Customer (KYC) verification. For consumers, the card owner and card assignee are typically the same person.; "customer" is the collective term.
• Beneficiaries are now trusted payeesTrusted Payee A trusted recipient for payments, including the business or individual's details and their bank account or instrument details. Sending to a Trusted Payee may let customers skip Strong Customer Authentication (SCA) on Outgoing Wire Transfer or Send transactions, reducing the number of approval steps required. Previously referred to as a Beneficiary. — a saved, reusable recipient, a payment to whom is exempt from Strong Customer Authentication each time. "Payee" is used for the recipient of a single payment.
• The change is reflected across the documentation and the API spec.
• The API spec has been reorganized from a flat list into intuitive functional groups (Customer Registration, Users & Authentication, Customer Settings, 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)., Funds Management, External Payments, Card Payments, In-Platform Payments, Bulk OperationsBulk Operations The capability of grouping multiple individual API-based actions into a batch. Bulk operations allow you to execute hundreds or thousands of operations by making only one or two API calls, increasing throughput, accomplishing actions in a secure session, and reducing complexity in your application.), so the spec reads as a journey rather than an alphabetical list.
• Non-breaking: endpoint paths, schema names, and field names are unchanged; only labels, grouping, and documentation wording change.

See the customers documentation and the Weavr API reference.