A merchant-initiated transaction is a payment triggered by a merchant after an initial customer authentication, such as a subscription renewal. Under SCA, the buyer generally needs to authenticate only once, but the merchant must still handle the transaction in a way that fits payment and regulatory rules.
How merchant-initiated transactions work
A merchant-initiated transaction starts with a valid initial customer-authenticated payment, then later uses that established payment relationship to charge again, often on a recurring schedule or after a service trigger.
The important distinction is that the later charge is not a fresh customer action. That means the transaction depends on the original authorisation flow, the stored payment credentials, and the rules attached to the payment scheme, gateway, and jurisdiction.
Where payment security and compliance matter
Merchant-initiated transactions sit in a security boundary between convenience and control. The merchant must preserve evidence of the original customer consent, manage the stored credential safely, and ensure the later charge is consistent with card-scheme and Strong Customer Authentication expectations.
This is why payment tooling, vaulting, and transaction metadata are not just back-office details. They determine whether the merchant can prove the payment relationship, reduce disputes, and avoid treating a subsequent charge as an unauthorised or improperly authenticated payment.
For the access and credential side of the problem, the right control mindset is similar to the broader governance discussed in OWASP Non-Human Identity Top 10 and the control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Common implementation patterns and edge cases
In practice, merchant-initiated transactions show up in subscriptions, usage-based billing, instalment plans, delayed capture workflows, and card-on-file operations. The underlying pattern is the same, but the evidence and approval model can differ depending on the scheme and the payment provider.
Edge cases usually arise when the original customer consent is vague, the stored credential has aged, or the merchant changes the amount, frequency, or purpose of the charge. Those changes can affect whether the later transaction still fits the original authorisation trail or needs a fresh customer interaction.
That is also why payment APIs and stored credential handling deserve careful authorisation design. The adjacent controls in OWASP API Security Top 10 and operational control discipline in OWASP Cheat Sheet Series are useful reference points when you are designing the surrounding payment flow.
Risk and Threat Considerations
Merchant-initiated transactions concentrate risk in the evidence trail, the stored payment credential, and the systems that decide when a later charge is still valid. If those controls are weak, a legitimate recurring-payment design can become a source of disputes, failed charges, or unauthorised billing exposure.
Failure mechanism: The merchant cannot reliably prove the original customer consent, mishandles credential storage, or sends a later charge outside the permitted transaction context, so the payment is treated as invalid, challenged, or exploitable.
Impact: The result can be chargebacks, customer trust loss, operational friction, revenue reversal, and regulatory or scheme non-compliance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Controls recurring payment access and stored credential use for merchant charging flows. |
| Recommendation — Restrict payment-system access and review who can create or trigger merchant-initiated charges. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Secrets and Credential Management | Covers stored payment credentials and sensitive tokens used to initiate later charges. |
| Recommendation — Protect stored payment credentials and rotate or revoke them when the payment relationship changes. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Applies because merchant-initiated transactions depend on controlled authorisation from the original payment relationship. |
| Recommendation — Preserve the original authorisation trail and enforce access control around recurring charge initiation. | ||
| PCI DSS v4.0 | 3 — Protect Stored Account Data | Merchant-initiated transactions often rely on stored payment data that must be protected across its lifecycle. |
| Recommendation — Store only the payment data needed for recurring charges and protect it throughout its lifecycle. | ||
Practitioner Guidance
Why practitioners should care: The practical question is not whether a later charge is convenient, but whether the merchant can defend it. Keep the original authorisation, transaction metadata, and stored-credential workflow consistent enough that disputes can be resolved without guesswork.
Common misunderstanding: Many teams assume a once-authenticated customer relationship is enough on its own. In reality, the later charge still needs the right transaction framing, scheme handling, and recordkeeping to stay defensible over time.
Practitioner takeaway: Treat merchant-initiated charging as a governed payment lifecycle, not as a simple repeat debit.
Related resources from NHI Mgmt Group
- What is the difference between entitlement review and transaction-first governance?
- How should security teams implement continuous transaction monitoring across business systems?
- When does transaction monitoring become more useful than manual review?
- What do organisations get wrong about transaction control assurance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
