Why Conventional ERP Payment Architecture Creates Unnecessary Scope
Most ERP payment integrations follow a deceptively simple flow:
Customer provides card data
→ ERP system receives full PAN + CVV + billing address
→ ERP forwards to payment gateway
→ Gateway returns authorization + token
→ ERP stores token for future transactions
The problem is in step two. The ERP system — with its order management modules, AR workflows, customer service interfaces, and recurring billing engines — receives the full Primary Account Number. Under PCI DSS v4.0, every system component that stores, processes, or transmits cardholder data, or that can impact the security of cardholder data, is in scope for the Cardholder Data Environment (CDE) assessment.
For a typical mid-market Dynamics 365 F&SCM environment, that means a non-trivial portion of your ERP is PCI-scoped: the order entry module, the AR payment journal, the customer service portal, the billing automation engine. Each one requires security controls, documentation, and audit validation.
The question architects should be asking is not "how do we secure all these systems?" but "why are all these systems receiving card data at all?"
Staged Authentication: The Architectural Alternative
Here's the architectural contrast:
CONVENTIONAL FLOW:
[Customer] --full PAN + CVV--> [ERP Order Entry]
[ERP Order Entry] --full PAN--> [Payment Gateway]
[Payment Gateway] --token--> [ERP Token Store]
Result: ERP touched full PAN. ERP is in PCI scope.
STAGED AUTHENTICATION FLOW:
[Customer] --partial identifier + order metadata--> [ERP Order Entry]
[ERP] --session token + partial ref--> [Secure Hosted Page]
[Customer] --remaining card digits + out-of-wallet factor--> [Secure Hosted Page]
[Secure Hosted Page] --auth request--> [Payment Gateway]
[Payment Gateway] --persistent token + auth result--> [ERP]
Result: ERP never touched full PAN. ERP scope dramatically reduced. which typically occurs after full PAN receipt. Here, full PAN assembly never happens within the merchant's systems at all.
PCI DSS v4.0 Scope Reduction: What Changes
Understanding scope reduction requires knowing how PCI DSS defines a Cardholder Data Environment (CDE).
Per PCI DSS v4.0 requirements, scope includes any system component that:
● Stores, processes, or transmits cardholder data or sensitive authentication data
● Can impact the security of cardholder data (connected-to systems)
● Provides security services to in-scope systems
Under a conventional integration, your ERP order entry module, AR interface, customer service portal, and recurring billing engine are likely all in scope because they interact with systems that handle full PANs.
Under a staged authentication model:
The merchant-side components handle only partial card fragments and order metadata. These do not constitute cardholder data under PCI DSS definitions (a partial PAN — fewer than the first 6/last 4 digits — falls outside the definition of a PAN that requires protection). This dramatically reduces which ERP components are in scope.
Practical SAQ impact:
For mid-market merchants completing SAQ-D (the most comprehensive questionnaire, applicable to merchants who don't qualify for simpler SAQ types), staged authentication can shift eligibility toward SAQ-A or SAQ-A-EP, depending on integration specifics. SAQ-A applies when all payment page functions are outsourced to PCI-compliant third parties and the merchant doesn't receive, process, or store card data. The staged model, implemented correctly, satisfies this structure for the card entry portion.
This has meaningful operational consequences — fewer systems to audit, lower QSA engagement costs, and reduced scope for security controls implementation.
Token Lifecycle for ERP-Native Recurring Transactions
Tokenization in an ERP context has requirements that simple e-commerce flows don't. ERPs manage long-term customer relationships, recurring billing cycles, intercompany transactions, and multi-channel payment surfaces. The token architecture needs to be persistent, portable across modules, and consistent across channels.
INITIAL TRANSACTION — token issuance
function processInitialPayment(orderId, customerId, sessionRef) {
// ERP has only: orderId, customerId, partial card ref, session token
// No full PAN ever enters this function
const authResult = await paymentGateway.completeAuth({
sessionRef: sessionRef,
orderId: orderId,
amount: order.totalAmount
})
// Gateway returns persistent network token
const persistentToken = authResult.networkToken || authResult.gatewayToken
// Store token on customer/account record in ERP
await erp.customerPaymentMethods.upsert({
customerId: customerId,
token: persistentToken,
maskedPan: authResult.maskedPan,
cardNetwork: authResult.network,
expiryMonth: authResult.expiryMonth,
expiryYear: authResult.expiryYear
})
return { authorized: true, token: persistentToken }
}
SUBSEQUENT TRANSACTIONS — token reuse
function processRecurringPayment(customerId, invoiceId, amount) {
const paymentMethod = await erp.customerPaymentMethods.get(customerId)
// ERP submits token — gateway translates to PAN internally
const authResult = await paymentGateway.chargeToken({
token: paymentMethod.token,
amount: amount,
invoiceRef: invoiceId
})
await erp.paymentJournals.post({
invoiceId: invoiceId,
amount: amount,
maskedPan: paymentMethod.maskedPan,
token: paymentMethod.token,
authCode: authResult.authorizationCode,
transactionId: authResult.transactionId
})
return authResult
}
Key architectural properties:
- ERP code path never contains a full PAN
- Payment journals store token references only
- Gateway handles token-to-PAN translation
- AR and billing modules operate entirely on tokens
Authentication Factor Design: Beyond CVV/AVS
Standard CNP (card-not-present) verification relies on three factors that share a critical weakness: all of them can be captured in a single data breach.
Conventional CNP verification:
✓ Card number (PAN)
✓ CVV
✓ Billing address (AVS)
Attack vector:
one compromised card file → all three factors satisfied
Staged authentication adds out-of-wallet factors that are not co-located with card data:
✓ Partial card reference
✓ Remaining card digits on isolated channel
✓ Email/phone on account
✓ Session binding
Attack vector:
compromised card file → cannot complete Stage 2
This aligns architecturally with the 3D Secure 2.0 (3DS2) model, which uses risk signals — device fingerprinting, behavioral analytics, transaction context — at the completion stage to authenticate without friction for legitimate users.
The staged authentication pattern for ERP-native transactions follows the same principle: multi-factor authentication is structural, not a bolt-on challenge triggered only when something looks suspicious.
Dynamics 365 Implementation Architecture
For teams building on Dynamics 365 F&SCM or Business Central, the architectural decisions that matter most:
Native payment framework vs. middleware connector:
The Dynamics 365 payment framework allows payment logic to run natively within the AX/D365 stack. This matters for reconciliation accuracy and scope containment.
External connectors that route ERP payment data through middleware create additional PCI scope questions.
Payment journal design:
A well-designed integration populates journal lines with:
- Customer account reference
- Invoice reference
- Amount
- Currency
- Masked PAN (first 6 / last 4)
- Payment token reference
- Authorization code
- Gateway transaction ID
NOT:
- full PAN
- CVV
- track data
*Omnichannel token consistency:
*
If payment surfaces include native order entry, B2B portals, mPOS/ePOS terminals, and customer service telephony, the token issued at any channel must be recognizable across all others.
This requires a common token vault that all channels reference.
Red Maple's native Dynamics 365 payment integration implements this architecture — split-entry authentication, gateway-agnostic token storage, and payment journal population with masked PANs only.
Fraud Pattern Disruption
Understanding the security value of staged authentication requires mapping it to how modern fraud patterns actually work.
Card testing attacks:
Automated bots submit micro-transactions across merchants to validate stolen card numbers. A staged architecture has no conventional auth endpoint. The bot cannot complete Stage 2 without the out-of-wallet factor.
**Account takeover (ATO):
**An attacker who compromises a merchant account may find token references stored in the customer record. Tokens without the associated verification factor are non-functional.
Insider threat:
This is the most underestimated vector in ERP environments. In a staged model, there are no full PANs in the database to extract. The insider threat surface is eliminated structurally, not mitigated procedurally.
Summary: When Staged Authentication Is (and Isn't) the Right Fit
Worth evaluating when:
- Your ERP has multiple modules interacting with payment data
- You're processing B2B recurring billing
- Your workflow includes manual order entry
- You need omnichannel token consistency
- You're on Dynamics 365 environments
Consider alternatives when:
- Your payment surface is a standalone hosted checkout
- Transaction volume is low
- You don't need ERP-native workflows
The core architectural principle remains consistent:
Reduce attack surface by reducing what your systems receive, not just by controlling what they store. reduce the attack surface by reducing what your systems touch, not just by protecting what they hold.
Further Reading
● PCI DSS v4.0 Requirements and Testing Procedures (PCI Security Standards Council)
● PCI DSS Tokenization Guidelines
● SAQ eligibility matrix — PCI SSC website
● EMVCo Token Specification
● Red Maple Clever Division documentation — redmaple.com
Top comments (0)