A delivery service between your collection system and the channels debtors actually read. It picks up the messages Nova or Aptic decide to send, renders them from case data, sends them through your SMS, email or payment provider, and writes what happened back on the case — so a failed send is a visible event rather than a silent one.
Collection platforms are good at deciding that a message should go out and poor at telling you
what happened next. When a reminder does not arrive, the question is always the same: was it
sent, was it accepted by the provider, and was it delivered? Message Gateway answers all three,
and puts the answer on the case where the handler will see it.
How a message travels
- Nova or Aptic books it. In Nova, a message is an ordinary workflow action, so action trees
and case handlers book SMS and email the way they book anything else. In Aptic it is the
e-message queue and action items. Operators can also send a message by hand from the web
interface, or park it as a draft for someone else to approve.
- The gateway renders it. A message profile holds the template, the recipient rule, the
provider and the sending window. Fields and formulas are filled from case and debtor data read
through your own data-source definitions, so a template can say remaining principal plus
half the interest without anyone writing code.
- A provider delivers it. Email over SMTP; SMS through LinkMobility, Vonage, Spirius or
SMSTeknik; payment requests through Swish, Strålfors, MobilePeople, LinkMobility Mobile
Invoice or your own payment-link service; operational alerts to a Microsoft Teams channel.
- What happened comes back. Delivery reports and payment callbacks arrive through a
Svalefelt-hosted callback endpoint — no inbound port on your side — or by polling. Replies by
SMS and by email are fetched and matched to the case; bounced email is analysed rather than
ignored. The result is written as a history note in Nova or Aptic, and every message keeps its
full status history in the gateway.
Rules an operator can set
- Sending windows. Which weekdays and hours a profile may send, with bank holidays taken from
the collection system's own calendar. A message generated outside the window waits.
- Valid time. How long the gateway keeps trying before it gives up and marks the message
failed.
- Retries. A provider or mail-server hiccup reschedules the message; a message in the
provider's hands is never sent twice.
- Priority profiles jump the queue when a notice cannot wait.
- Recipient rules. Debtor, customer, creditor, an estate or bankruptcy administrator, a fixed
address, or a custom recipient resolved by a query of your own.
Event handlers
An event handler is what happens after a message leaves. A trigger fires on a delivery status, on
a reply that matches a text, or on an action registered in the source system; the actions that
follow can write a history note, send another message, run a query or call a web service. That is
how not delivered becomes a note on the case and an alert in the operations channel, and how
STOP from a debtor becomes a flag rather than a message nobody read.
Safe to test against live data
A provider can be limited to a list of test recipients, so a test system connected to a copy of
production can only ever reach a few known addresses. The simulator provider keeps messages on
the machine and lets you play the provider — delivered, failed, bad address, paid — and the rest
of the system reacts exactly as it would to a real one. The profile tester renders a profile
against a real case and shows who it would have gone to, without sending anything.
Built to be operated
The web interface shows what the gateway is doing right now: the dashboard counts messages at
every stage and per profile, the outgoing and incoming lists filter by state, and every case and
every recipient has a page with its whole correspondence. Any background process — receiving,
matching, sending, recalling, status refresh, synchronisation — can be paused on its own during
maintenance and resumed a second later, without restarting the service. Logs are readable in the
browser, the system page shows fifteen-minute performance metrics, and an optional admin API
exposes health, Prometheus metrics and job control to your monitoring.
One service instance serves one collection system; several instances run side by side on one
server when you serve more than one company. The service runs on Windows, Linux or Docker, talks
to the broker over TLS, and writes an append-only log of everything it did.
Message Gateway is in daily use at collection agencies across the Nordics.
