Card transaction notifications are messages sent to a cardholder’s device or to your own systems each time something happens on a business card: an authorization, a decline, a status change. For a company, they are the fastest way to see spending as it happens and to catch an unrecognized payment before it grows into a loss. This guide explains what an alert contains, which channels exist, how to configure them for a company card programme, and what to do when an alert looks wrong.

DemivoltKeep Business Card Spending in ViewDemivolt offers business cards alongside payment solutions, helping companies manage card expenses within their digital financial infrastructure.Explore Demivolt

TL;DR

A card notification is an event message: it reports transactions, card-status changes or other timely information, and it can reach a cardholder’s phone or a webhook endpoint in your own system.
A typical authorization alert shows the date and time, the card, the amount and currency, the status, the balance and the merchant.
Alert types and events are usually defined during integration or on request, so decide in advance who receives what.
An alert you do not recognize is a signal to block the card, preserve the evidence and contact your provider and, if money was lost, the police.
For a company, the best setup separates cardholder alerts from finance-team alerts and keeps a record of every notification.

What a card transaction notification is
What an alert can show
Delivery channels and speed
How to set up notifications for a company card programme
Roles: who should receive which alert
What to do when an alert looks wrong
Reading declines correctly
Security and privacy in Lithuania
Are notifications free?
A working alert policy for a small company
Our perspective
Set up cards with the controls built in
Checklist before you go live
FAQ
Sources

What a card transaction notification is

In card-issuing documentation, a notification is defined as a message sent to the cardholder’s device about card-status changes, transactions or other timely information. DECTA’s Issuing API documentation describes this model, and it is a useful reference for how event-driven alerts work in card issuing generally.

Two kinds of messages matter for a business:

Messages to a person. An SMS or push message that tells the cardholder what just happened on the card.
Messages to a system. A push webhook: an automatic call to a URL you designate, sent as soon as a new event occurs. Your accounting tool, expense platform or internal dashboard receives the data without anyone opening a banking portal.

The second kind is what turns a card from a payment instrument into a data source. A finance team that receives every authorization as a structured event can match it to a purchase order, flag it against a budget or route it for approval.

What an alert can show

The same documentation gives an example of a card-authorization SMS. It can report the date and time, the card identifier, the amount, the currency, the status of the operation, the remaining balance and the merchant details. In practice, these fields answer five questions in a few seconds:

Field	The question it answers
Date and time	Did this happen when we expected a payment?
Card identifier	Which card, and so which employee or budget?
Amount and currency	Is the sum plausible, and was a foreign-currency conversion involved?
Status	Was it approved, declined or reversed?
Balance	Is there enough left for the next scheduled payment?
Merchant	Do we know this vendor?

The exact content of your alerts depends on how your card programme is configured, so confirm the final template with your provider rather than assuming the example above.

Delivery channels and speed

There are two channels worth planning for:

SMS to the cardholder. Simple and works without an app. It suits employees who carry a card but do not use a finance tool.
Push webhooks to your systems. According to the same documentation, these are triggered as soon as a new event happens. Authorization events are produced when the authorization occurs, and a business can route them onward, including to SMS or push, once the integration is configured.

The practical consequence is that alert speed is a property of the whole chain: the issuer produces the event, and your configuration decides who sees it and how quickly. A webhook that lands in an unmonitored inbox is no faster than a monthly statement.

How to set up notifications for a company card programme

Notification types and events are set during project integration or on request. That means the work happens at the start of a card programme, and it is cheaper to do it then than to retrofit it. A workable sequence:

List the events you need. Start with authorizations, declines, refunds and card-status changes such as blocking or expiry. Add balance thresholds if cards draw on a shared account.
Decide the recipients per event. Cardholders see their own transactions. The finance lead sees declines, foreign-currency spending and large amounts. An administrator sees status changes.
Choose the channel per recipient. SMS for individuals, webhooks for finance systems.
Define thresholds. For example, any transaction above a fixed amount, any transaction outside your usual merchant categories, or any card-not-present payment from a card that is normally used in person.
Test with a small live transaction and check that the alert arrives at every destination with the fields you expect.
Store the notifications. Keep them with your accounting records so that a disputed payment can be traced later.

If you issue cards through Demivolt card programmes, your Dedicated Client Manager is the right contact for confirming which alert options apply to your programme.

Roles: who should receive which alert

A small company can send everything to one founder. Once there are five cards, that stops working. Role-based access matters here, because the people who spend are not the people who control.

Cardholder: gets alerts for their own card only. This builds the habit of reporting something that was not them.
Finance lead or CFO: gets declines, large transactions and anything in a foreign currency. Declines are as informative as approvals: a burst of declines at an unfamiliar merchant is a classic sign of testing by a fraudster.
Account administrator: gets card-status changes, new-card issuance and limit changes.
Advisor or external accountant: if they handle your books, they may receive a data feed rather than personal alerts.

Keep the principle of least information: an alert showing a balance goes only to people who are meant to know the balance.

What to do when an alert looks wrong

A notification is only useful if someone acts on it. Build a short written procedure so that the person who receives an unfamiliar alert does not need to decide what to do under pressure.

Step 1: Check before panicking

Some payments look strange but are not. Subscriptions are billed under the processor’s name rather than the vendor’s. Hotels and car rentals place a pre-authorization that differs from the final charge. A foreign-currency purchase shows the converted amount. Ask the cardholder first, but give them a short window, such as an hour.

Step 2: Block the card

If nobody recognizes the payment, block or freeze the card at once. Blocking stops further misuse, and a replacement can be issued afterwards. Do not wait for a callback.

Step 3: Preserve the evidence

Do not delete SMS messages, emails or chats connected with the incident. Screenshots of the alert, the time you noticed it and any suspicious message the cardholder received are what your provider and the police will ask for. A recent Lithuanian guide on responding to banking fraud makes the same point, noting that evidence should be kept even after a card is blocked, and that an electronic report to the police can be submitted through the ePolicija portal (Ulteh guide).

Step 4: Contact your provider

Report the transaction and ask for it to be investigated. The dispute process is run by the provider that issued the card, so give them the time, amount, merchant and your evidence in one message.

Step 5: Report and review

If money was taken or credentials were shared, report it to the police. Then review the cause: was a card number saved on an unprotected page, was a one-time code given to a caller, was a former employee’s access still active? Our guide to card fraud prevention for businesses in Lithuania covers the prevention side in more detail.

Reading declines correctly

A decline alert is not always fraud. Common causes include insufficient balance, a limit reached, an expired card, a wrong CVV or a merchant category that your programme blocks. Payment processors that publish decline-code lists describe codes such as “do not honor” and “refer to issuer” as the issuer refusing the transaction, with the usual advice to try another payment method and have the cardholder contact the issuer (Tidal Commerce decline code list). For your own team, translate this into a simple rule:

Decline pattern	Likely meaning	Action
One decline at a known vendor	Limit or balance	Check the limit, top up if needed
Several declines in a row at an unknown merchant	Card testing	Block the card immediately
Decline on a card that was not used	Possible misuse of stored data	Block and reissue
Decline after a card renewal	Vendor still holds old card details	Update the vendor’s record

Security and privacy in Lithuania

Alerts carry financial data, so treat them as such.

Strong customer authentication still applies. Under the revised Payment Services Directive (PSD2), providers must confirm a customer’s identity with at least two of three elements: possession, knowledge and inherence. The Bank of Lithuania set out this principle when the rules were introduced. A notification is not authentication, and a message that asks you to reply with a code or click a link to “cancel” a payment should be treated as a scam attempt.

Protect the delivery points.

Use a company phone number controlled by the business for cardholder SMS where possible, so that a departing employee’s number does not keep receiving data.
Secure your webhook endpoint: accept calls only over an encrypted connection, verify that they come from your provider and log every call.
Limit who can read the stored notifications.

Mind personal data. An alert tied to a named employee is personal data under EU data-protection rules. Keep the retention period proportionate and tell staff what is monitored.

Do not share one-time codes. No legitimate provider asks for them by phone or chat.

Are notifications free?

This depends on the provider and the programme: some include SMS in the card fee, others charge per message, and webhooks are usually part of the integration rather than a separate line. Ask three questions before you commit: is SMS charged per message, are there limits on volume, and which events can be switched on. With Demivolt, account opening, verification, the Dedicated Client Manager and monthly maintenance are listed at 0, and the published payment fees are SEPA In at 0 €, SEPA Out at 0.40 €, SWIFT In at 25.00 € and SWIFT Out at 30.00 €. For notification terms specific to your programme, ask your client manager.

A working alert policy for a small company

A one-page policy is enough. It should state:

Who holds each card and who receives each alert type.
The response time for an unrecognized transaction, for example one hour during working hours.
Who can block a card, and that anyone may do so without asking permission.
Where evidence is stored.
A monthly review in which finance compares alerts with the statement and removes access for people who have left.

The most common failure is not technical. It is an alert that arrives, is seen by someone who assumes it is another person’s job, and is ignored. Name an owner.

Our perspective

For a business, a card alert is a control, not a convenience. Cards are spent by many people but accounted for by few, and the gap between the two is where errors and fraud live. Real-time events close that gap, provided each event reaches the right person.

We build business banking on that principle. A regulated account with a dedicated IBAN, segregated client funds, role-based user management and cards issued under clear programme rules gives a finance team the structure alerts need: every card tied to a person, every person tied to a role, every role tied to what it may see.

Alerts work best when they are part of the design of the account, not an afterthought. That is why we recommend deciding recipients, thresholds and escalation steps when the card programme is set up, with your Dedicated Client Manager, and reviewing them as the team grows. Transparent fees help too: a company should know what its payment and card activity costs before it sets thresholds around it.

dd

Set up cards with the controls built in

If your company is opening a business account or planning a card programme, define the alert structure at the start. Demivolt business accounts offer dedicated IBANs, multi-account structures and role-based user management, and our Visa business cards can be issued as virtual or physical cards for expenses. Account opening, verification and monthly maintenance carry no fee.

To see how payments and cards fit together for your cross-border operations, review our payments solutions, or get started and contact us to discuss your card programme.

Checklist before you go live

Events selected: authorizations, declines, refunds, status changes.
Recipients mapped to roles, with no one receiving more than they need.
Channels tested end to end, including the webhook.
Thresholds defined for amount, currency, merchant type and card-not-present use.
Block procedure written, with a named person for each shift or absence.
Notification records stored with the accounting data.
Review date set for the first month and then every quarter.

FAQ

What is a card transaction notification?

It is a message about an event on a payment card, such as an approved or declined payment or a status change. It can go to the cardholder’s device by SMS or push, or to a URL you designate through a webhook. The content typically includes the amount, merchant, status and time.

Can I choose which notifications my company receives?

Usually yes. Notification types and events are generally set during project integration or on request. Decide them with your provider when the card programme starts, and ask for changes when your team or spending patterns change.

What should I do if I receive an alert for a payment I did not make?

Block the card immediately, keep all related messages and screenshots, and report the transaction to your provider. If money was lost or credentials were shared, file a report with the police, which in Lithuania can be done electronically. Afterwards, find out how the card data was exposed.

Can a notification itself be a scam?

Yes. Fraudulent messages imitate real alerts and ask you to click a link, call a number or share a code. A genuine alert informs you of an event and never asks for a one-time code or full card details. If in doubt, open your account directly instead of using the message.

Card Transaction Notifications for Business Cards