The Hidden Complexities of Converting Between SMS and DMS Payment Flows

Back to all posts

Some payment systems operate with a Dual Message System (DMS) where the authorization and capture messages are kept separate, while others use Single Message System (SMS) where authorization and capture are combined.

Converting between them is far more nuanced than it first appears, so let's explore some gotchas that arise when integrating payment networks that use different message systems; from subtle pitfalls that can cause performance degradation to reconciliation issues, all the way to regulatory problems.

SMS to DMS: The Performance Trap

Let's start with what appears to be the simpler direction: converting an SMS request into DMS operations. The logic seems straightforward:

1. Receive SMS payment request from acquirer
2. Initiate DMS authorization towards issuer
3. Upon authorization approval, immediately issue DMS capture request
4. Upon capture confirmation, return response to SMS caller (i.e., the acquirer)

This works but it's slower than necessary: by awaiting the DMS capture result before responding to the SMS request, we've unnecessarily degraded our system's performance. Why? Because all the SMS caller needs is confirmation they will get their money: while the capture will trigger the movement of the money, the confirmation information comes from the DMS authorization step as that is what results in a conditional payment guarantee from the issuer towards the acquirer.

In other words, the scheme can respond to the caller as soon as the authorization resolves. This will be much faster as there's no need to await an extra call. Additionally the issuer may process capture requests slower than authorizations as they typically aren't time sensitive: during authorization, you've got a customer growing impatient, while the capture process is just machines coordinating without any human waiting around on the result.

So we want to avoid blocking on the capture so we don't force the calling acquirer to wait for two network round-trips plus processing time instead of one. In a high-throughput payment system, this additional latency compounds quickly!

Let's instead have our cake and eat it, too: we can maintain the performance characteristics the SMS caller expects while properly executing the DMS flow under the hood by responding to the SMS caller as the authorization succeeds and deferring the capture call. Easy peasy!

But before you go on your merry way, let's have a quick chat about settlement...

The Settlement Period Problem

When you respond to an SMS request based solely on authorization approval, you've made an implicit promise: the payment will settle in the period the caller expects. This is where things get tricky.

In the land of DMS, settlement will happen according to the period defined by a capture, regardless of when (or even whether!) the authorization took place. So if the authorization completes right before the settlement period's cutoff and the capture only happens later (within the next settlement period), congratulations: you've just split a single logical payment across two settlement periods with the acquirer expecting the money earlier than the issuer is going to send it.

What do I mean? The SMS caller will be reconciling against their expected settlement period, i.e., the settlement period in which their SMS payment call succeeded. However, on the issuing side, that same transaction will only settle in the following period (i.e., when it was captured). Result: the acquirer's accounting won't balance and reconciliation is now necessary.

To a degree, dealing with these reconciliations is a "cost of doing business". The acquirer will be provided a clearing report by the payment scheme and will verify it according to its own records. While the specifics of reconciliation will differ across schemes and specific integrations, transactions present in the acquirer's records but missing from the scheme's clearing reconciliation report will be monitored: typically, if they fall within a known "problem period" they will be assumed to have overflowed into the next settlement period and if they don't show up in the next clearing report the discrepancy will be flagged towards the scheme. Alternatively, the scheme being aware of the quirks of SMS to DMS conversion may also proactively list the transactions straddling two settlement periods in an accompanying exception report to confirm to the acquirer that these transactions will indeed be settled, but in a later period.

Auto-Capture to the Rescue (?)

One possibility to make the settlement timing more obvious, at the expense of surfacing a somewhat leaky abstraction, is to expose an "auto capture type" attribute on the acquiring side:

• async auto-capture: the scheme will respond to the SMS payment as soon as authorization had been approved, and capture will happen later. Given the acquirer has more knowledge about the specifics of capture mechanics, it can be on the lookout for payments that straddle settlement periods.
• sync auto-capture: the scheme will await the capture result before responding to the SMS payment request. While this doesn't get rid of reconciliation issues (capture could happen in settlement period S, with the SMS payment confirmation resolving in period S+1), it makes the reconciliation process easier on the acquiring side as the payment will settle sooner than expected: the acquirer can look up their settlement ledgers and update the record for payment in question.

While many schemes settle once daily, there is a tendency in the industry to move towards multiple intra-day settlement periods (as can be the case with semi-instant payments) which will only exacerbate the reconciliation problem at hand.

Converting DMS to SMS: Limited Viability

Now let's tackle the more challenging direction: converting DMS into SMS. This can work, but only under constrained circumstances.

The key insight is that DMS authorization provides a conditional payment guarantee: funds are reserved but not yet moved. SMS, by contrast, is an unconditional payment: the funds are immediately cleared from the customer's account and marked for settlement. To bridge this gap, you need to ensure the DMS capture lands in the same settlement period.

Here's the pattern that can work:

1. Only authorize if the authorization's validity is set to expire shortly before the settlement cutoff (to "force" capture within the same settlement period)
2. Convert the DMS authorization into an SMS payment
3. If capture occurs before expiry, great—the payment settles normally
4. If no capture occurs, the authorization expires and the SMS payment gets reversed in the same settlement period

The critical constraint: the payment reversal must occur within the same settlement period. This way, the clearing reports will be consistent with the payment never having taken place:

• in the acquirer reports, the payment will be completely absent (it was never captured)
• in the issuer reports, the payment will either (depending on scheme rules)
  • be completely absent
  • be present along with its reversal, canceling each other in the netted result

The Multi-Period Problem: Watch for Regulatory Compliance

What if you need to support DMS authorizations that span multiple settlement periods? This is where we hit a hard wall.

An approved DMS authorization is a payment guarantee. The funds must be reserved somewhere. When converting to SMS, this means:

1. You process the SMS payment immediately (funds are moved), since SMS setups typically don't have any ability to reserve funds
2. Those funds must now be held somewhere, awaiting capture
3. If capture never arrives, you eventually refund the payment

Regulators are going to have a lot to say to you about step 2: you are now holding customer funds. At the minimum, this requires an e-money license in most jurisdictions and most schemes and payment service providers don't possess one; e-money licenses come with significant regulatory overhead, capital requirements, and ongoing compliance costs.

Without en e-money license (or being a regulated entity, i.e., a bank), you simply cannot hold customer funds. Which means you cannot convert multi-period DMS authorizations into SMS payments. The regulatory framework doesn't allow it.

Some might argue you could hold funds in escrow or use other mechanisms. In practice, these either require the same e-money licensing or introduce complexities (third-party escrow providers, additional fees, reconciliation overhead) that make the solution untenable for most use cases.

Practical Implications

What does this mean for real-world implementations? You need to be crystal clear about which conversions you support:

• SMS → DMS: Fully supported, but requires careful response timing and settlement period tracking
• DMS → SMS (same-period): Supported with constraints on authorization validity
• DMS → SMS (multi-period): Not viable without e-money licensing

Document these limitations explicitly. Your API contracts should specify whether multi-period DMS authorizations are supported, what happens at settlement boundaries, and how reconciliation works.

And if you're integrating with a payment provider, ask these questions during the evaluation phase. Don't assume the conversion will work the way you need it to. The devil is in the details: specifically, in settlement periods, regulatory constraints, and performance characteristics.

Wrapping Up

Converting between SMS and DMS isn't impossible, but it requires deep understanding of payment scheme mechanics, settlement timing, and regulatory frameworks. The patterns that seem intuitive often hide gotchas that only reveal themselves in production: degraded performance, reconciliation failures, or outright regulatory violations.

But once you understand these constraints, you can design systems that work within them. The key is recognizing that message system conversions aren't just protocol translations: they're bridging fundamentally different payment guarantees and settlement behaviors. Respect those differences, and your integrations will be robust. Or just ignore them if you'd rather be debugging production issues at night...