Automating SEPA Direct Debit on Shopify via Mollie: The Technical Blueprint for European Merchants

For e-commerce merchants scaling subscription models across Europe, relying solely on Visa and Mastercard is a costly strategic oversight. Credit card penetration across Continental Europe remains fractured: Dutch consumers complete the vast majority of online transactions via iDEAL, German shoppers prefer bank transfers and Lastschrift, and Belgian buyers lean heavily on Bancontact. Forcing European customers into credit card checkout funnels increases acquisition drop-off, while card expiration cycles drive significant involuntary churn.
Automating SEPA Direct Debit (SDD) on Shopify via Mollie bridges this conversion gap. By pairing Shopify’s native Subscription APIs with Mollie’s automated mandate engine, merchants unlock recurring access to bank accounts across 36 SEPA-compliant countries. This technical guide outlines the system architecture, e-mandate onboarding flows, API integration patterns, compliance rules, and automated dunning workflows needed to operate SEPA Direct Debit at scale.
1. Architecture and Feasibility: SEPA Direct Debit for Shopify Subscriptions
Automating SEPA Direct Debit on Shopify via Mollie requires bridging Shopify's Subscription Contracts API with Mollie’s Customers and Mandates infrastructure, using initial authenticated payments to capture electronic debit authorizations. This architecture reduces transaction processing costs compared to card interchange fees while virtually eliminating involuntary churn from expiring cards.

The Economics of SEPA vs. Credit Cards for European Subscriptions (DACH, Benelux, and France)
For European direct-to-consumer (DTC) brands and B2B merchants, payment processing economics hinge on interchange regulations, scheme fees, and domestic payment behaviors. While consumer interchange fees are capped across the European Union under the Interchange Fee Regulation overseen by the European Central Bank, acquiring markups, card network scheme fees, and cross-border assessments routinely elevate blended credit card processing costs above direct bank debit rails.
| Payment Rail | Fee Structure | Involuntary Churn Risk | Settlement Time | Regional Adoption (Core Markets) |
|---|---|---|---|---|
| Credit Cards (Visa/Mastercard) | Blended percentage + fixed fee | High (Card expiration and lost cards) | 1–3 Business Days | High (UK, France), Lower in Germany, Netherlands |
| SEPA Direct Debit (via Mollie) | Flat fee per transaction [Mollie Pricing] | Low (Account closure only; IBAN persistence) | 1–3 Business Days | Dominant across DACH, Benelux, France, Nordics |
| PayPal Subscriptions | Percentage + fixed fee | Moderate (Funding source expiration) | Instant to Wallet | Moderate across Western Europe |
In subscription commerce, the primary financial drain is not simply the fee percentage—it is involuntary churn. Credit and debit cards expire periodically, get replaced due to loss or fraud, or hit arbitrary spending limits. By contrast, a customer's International Bank Account Number (IBAN) remains persistent across decades. Replacing card billing with SEPA Direct Debit drops involuntary payment failures to negligible levels, immediately improving customer lifetime value (LTV).
High-Level System Architecture: Bridging Shopify Checkout, Subscription Contracts, and Mollie
Shopify's modern subscription infrastructure separates checkout authorization from subscription contract execution. When a shopper purchases a recurring product, Shopify generates a SubscriptionContract resource managed through the Shopify Subscription APIs.
Because Shopify Payments does not natively process recurring SEPA Direct Debit through its built-in gateway in all European locales, Mollie acts as the external recurring payment orchestrator:
[ Customer Checkout ]
│
▼
[ Initial Payment via iDEAL / Bancontact / Auth ] ───▶ [ Mollie Checkout Engine ]
│
▼
[ Shopify Order Created ] ◀── [ Webhook: payment.paid ] ── [ Generate Customer (cst_) & Mandate (mdt_) ]
│
▼
[ Create SubscriptionContract ] ── Store cst_xxx & mdt_xxx in Metafields
│
│ (Recurring Billing Schedule)
▼
[ Middleware / Engine ] ─── POST /v2/payments ───▶ [ Mollie SEPA Processing Rail ]
│ │
▼ ▼
[ subscriptionBillingAttemptCreate ] ◀── Webhook: paid ────── [ Clearing & Settlement ]
- Checkout Initiation: The customer checks out on Shopify, selecting an initial authenticated payment method (e.g., iDEAL in the Netherlands, Bancontact in Belgium, or an initial SEPA authorization transaction).
- First-Payment Mandate Tokenization: Mollie captures the bank details through Strong Customer Authentication (SCA), spawning a persistent Customer ID (
cst_xxx) and an active Mandate ID (mdt_xxx) via Mollie's recurring payments framework. - Contract Registration: The subscription middleware captures Mollie’s webhook, updates Shopify with the customer's payment token, and registers the recurring billing cycle.
- Scheduled Charge Execution: When the billing interval triggers, the orchestrator requests a recurring charge against the stored mandate via Mollie’s REST API, monitors the settlement lifecycle, and confirms the billing attempt to Shopify.
Choosing Your Stack: Pre-Built Shopify Subscription Apps vs. Custom Webhook Architectures
Merchants must choose between configuring an off-the-shelf Shopify subscription app with Mollie integrations or deploying a bespoke serverless middleware.
- Pre-Built App Ecosystem (Appstle, Recharge, Seal Subscriptions, Bold):
- Pros: Rapid deployment, pre-configured customer self-service portals, out-of-the-box Shopify Customer Account integration.
- Cons: Most pre-built apps rely primarily on Stripe or Shopify Payments for direct debit, limiting multi-gateway routing. Those supporting Mollie often require enterprise-tier plans and provide limited visibility into granular bank rejection codes (R-transactions).
- Custom Serverless Architecture (Node.js/TypeScript on AWS Lambda or Cloudflare Workers):
- Pros: Direct programmatic control over mandate state transitions, zero app revenue-share fees, custom transactional pre-notification delivery via Klaviyo or Postmark, and precision dunning logic aligned with bank clearing schedules.
- Cons: Requires custom development to handle Shopify checkout extension interfaces, webhook retry queues, and legal audit logs.
For brands scaling their recurring revenue operations, building or extending a dedicated connector to Mollie yields substantial long-term savings and operational resilience.
2. E-Mandate Lifecycle Automation: From First-Payment Auth to Active Mandate
A valid electronic SEPA mandate is established in Mollie by executing an initial authenticated first transaction—via iDEAL, Bancontact, or a verification payment—with sequenceType: "first". This binds the debtor’s IBAN to a Mollie customer object and generates an active mandate token (mdt_xxx) capable of authorized recurring collections.

Generating Valid Electronic Mandates via Initial Authentication (iDEAL, Bancontact, and Verification Payments)
Under European direct debit standards detailed by the European Central Bank, a creditor must obtain an explicit mandate before debiting an account. Traditional paper mandates or bare unverified web forms (asking solely for an IBAN and BIC) carry massive chargeback and fraud vulnerabilities; anyone can enter an arbitrary IBAN.
To eliminate fraud, European payment infrastructure relies on first-payment authentication. Instead of collecting manual bank account details, the customer authenticates via an instant banking rail:
- iDEAL (Netherlands): The customer authorizes their initial subscription charge via their bank app. The transaction captures the account holder's verified name, IBAN, and BIC.
- Bancontact (Belgium): The initial transaction authenticates the cardholder, linking back to their underlying bank account.
- Bank Verification (DACH / General SEPA): For subscriptions offering free trials or deferred billing, merchants execute a micro-authorization (such as €0.01). Once authenticated through online banking, Mollie extracts the verified debtor details, completes the payment, and issues the mandate.
How Mollie Generates, Registers, and Stores Mandate IDs (mdt_xxx) and Customer Tokens
The programmatic process of binding a consumer to a recurring direct debit mandate requires two sequenced calls to Mollie's REST API.
Step 1: Create a Mollie Customer Record
Before processing the initial payment, create a customer object within Mollie to hold all future payment methods:
curl -X POST https://api.mollie.com/v2/customers \
-H "Authorization: Bearer test_dHar4XY7LxsDOtmnkVtjNVWPeachdn" \
-H "Content-Type: application/json" \
-d '{
"name": "Henrik Lindqvist",
"email": "henrik.lindqvist@example.de",
"metadata": {
"shopify_customer_id": "gid://shopify/Customer/7182930192"
}
}'
This returns a persistent customer identifier:
{
"resource": "customer",
"id": "cst_8wmqcHMN4U",
"mode": "live",
"name": "Henrik Lindqvist",
"email": "henrik.lindqvist@example.de",
"createdAt": "2026-03-10T14:22:18+00:00"
}
Step 2: Initialize the "First" Payment to Create the Mandate
Next, initiate the initial checkout payment. Setting sequenceType: "first" instructs Mollie to convert the transaction into a recurring authorization:
curl -X POST https://api.mollie.com/v2/payments \
-H "Authorization: Bearer test_dHar4XY7LxsDOtmnkVtjNVWPeachdn" \
-H "Content-Type: application/json" \
-d '{
"amount": {
"currency": "EUR",
"value": "29.90"
},
"customerId": "cst_8wmqcHMN4U",
"sequenceType": "first",
"description": "Initial Order #1001 - Monthly Coffee Subscription",
"redirectUrl": "https://store.example.com/checkout/order-received",
"webhookUrl": "https://api.store.example.com/webhooks/mollie",
"method": "ideal"
}'
Once the consumer authenticates through their bank, Mollie records the payment, extracts the verified IBAN, and generates a mandate object (mdt_p3NX7rSr2u). Inspecting the mandate reveals the details:
{
"resource": "mandate",
"id": "mdt_p3NX7rSr2u",
"status": "valid",
"method": "directdebit",
"details": {
"consumerName": "H. Lindqvist",
"consumerAccount": "NL91ABNA0417164300",
"consumerBic": "ABNANL2A"
},
"mandateReference": "MD71829-1001",
"signatureDate": "2026-03-10",
"createdAt": "2026-03-10T14:25:01+00:00"
}
Managing Mandate Status Transitions: Handling Pending, Valid, and Revoked States
Mandates are dynamic legal authorizations that cycle through multiple states:
┌────────────────┐
│ PENDING │ (Initial direct debit verification)
└───────┬────────┘
│ Bank verification succeeds
▼
┌────────────────┐
┌──────────────▶│ VALID │ (Ready for recurring charges)
│ └───────┬────────┘
│ │
│ Account updated ├──────────────────────────────┐
│ or re-authenticated │ Debtor revocation │ Invalid details /
│ │ or bank dispute │ sustained failure
│ ▼ ▼
│ ┌────────────────┐ ┌────────────────┐
└───────────────│ REVOKED │ │ INVALID │
└────────────────┘ └────────────────┘
- Pending: Occurs when an initial mandate is generated via a direct debit submission rather than an instant rail (e.g., standard SEPA auth). No recurring charges should be submitted until clearance.
- Valid: The mandate has been verified, authenticated, and can immediately receive
sequenceType: "recurring"charges. - Invalid / Revoked: Triggered when the customer instructs their bank to block debits from your Creditor Identifier (CID), when the account is closed, or when Mollie marks the mandate unserviceable following sustained chargebacks.
Your webhook handler must monitor mandate events. When a mandate is revoked, your application must update the SubscriptionContract status in Shopify to PAUSED and dispatch a notification prompting the customer to re-authenticate their payment details.
3. Implementation Blueprint: Connecting Shopify to Mollie Recurring Payments
Connecting Shopify to Mollie recurring payments requires synchronizing Shopify subscription billing cycles with Mollie's /v2/payments endpoint using sequenceType: "recurring" and target mandate IDs. Because SEPA transactions clear asynchronously over several banking days, your system must track pending payment statuses before confirming billing attempts back to Shopify.

Setting Up Mollie Recurring Payments and Webhook Listeners for Shopify Store Events
Mollie uses an asynchronous status notification model: when an event occurs, Mollie posts an id string via application/x-www-form-urlencoded to your webhook URL. Your backend must listen for this ID and call the Mollie API to inspect the updated resource.
Here is an implementation of a secure webhook listener built in Node.js/Express:
import express, { Request, Response } from 'express';
import createMollieClient from '@mollie/api-client';
const app = express();
app.use(express.urlencoded({ extended: true }));
app.use(express.json());
const mollieClient = createMollieClient({
apiKey: process.env.MOLLIE_API_KEY!
});
app.post('/webhooks/mollie', async (req: Request, res: Response) => {
const paymentId = req.body.id;
if (!paymentId) {
return res.status(400).send('Missing payment ID');
}
try {
const payment = await mollieClient.payments.get(paymentId);
// Process payment status transitions
switch (payment.status) {
case 'paid':
await handlePaymentPaid(payment);
break;
case 'failed':
case 'canceled':
case 'expired':
await handlePaymentFailure(payment);
break;
case 'pending':
// SEPA direct debits remain in pending during bank clearing
await handlePaymentPending(payment);
break;
default:
console.log(`Unhandled payment status: ${payment.status}`);
}
// Always respond with 200 OK to acknowledge receipt to Mollie
return res.status(200).send('OK');
} catch (error) {
console.error(`Webhook processing failed for ${paymentId}:`, error);
return res.status(500).send('Internal Server Error');
}
});
Mapping Shopify Subscription Billing Cycles to Mollie Customer and Mandate Records
Shopify represents recurring purchases using its SubscriptionContract GraphQL object. Store the corresponding Mollie IDs directly within the contract's custom attributes during the initial checkout fulfillment:
mutation CreateSubscriptionContractMetafields($input: SubscriptionContractUpdateInput!) {
subscriptionContractUpdate(
contractId: "gid://shopify/SubscriptionContract/1049281729",
input: {
customAttributes: [
{ key: "mollie_customer_id", value: "cst_8wmqcHMN4U" },
{ key: "mollie_mandate_id", value: "mdt_p3NX7rSr2u" }
]
}
) {
contract {
id
status
}
userErrors {
field
message
}
}
}
By persisting cst_xxx and mdt_xxx inside the contract's custom attributes, your recurring billing engine can quickly resolve the appropriate credentials when Shopify issues billing interval webhooks.
Executing Automated Recurring Charge Requests (POST /v2/payments) on Billing Schedules
When a subscription cycle triggers (or a scheduled worker detects an active billing interval), your backend executes a recurring direct debit transaction against Mollie's API.
Step 1: Dispatch the Recurring Debit
Execute a POST /v2/payments call with sequenceType: "recurring":
async function executeRecurringBilling(
customerId: string,
mandateId: string,
amount: string,
subscriptionContractId: string
) {
const recurringPayment = await mollieClient.payments.create({
amount: {
currency: 'EUR',
value: amount, // e.g., "29.90"
},
customerId: customerId,
mandateId: mandateId,
sequenceType: 'recurring',
description: `Renewal for Contract ${subscriptionContractId}`,
webhookUrl: 'https://api.store.example.com/webhooks/mollie',
metadata: {
shopify_subscription_contract_id: subscriptionContractId,
},
});
return recurringPayment;
}
Step 2: Synchronize the Billing Attempt with Shopify
Because SEPA Direct Debit transfers clear asynchronously across banking settlement cycles, Mollie marks the newly generated payment as pending upon creation according to Mollie's payment lifecycle.
Do not mark the Shopify billing attempt as failed or immediately finalized. Instead, generate a pending billing attempt record via Shopify's GraphQL API:
mutation RecordBillingAttempt($subscriptionContractId: ID!, $idempotencyKey: String!) {
subscriptionBillingAttemptCreate(
subscriptionContractId: $subscriptionContractId,
subscriptionBillingAttemptInput: {
idempotencyKey: $idempotencyKey,
originTime: "2026-03-10T00:00:00Z"
}
) {
subscriptionBillingAttempt {
id
ready
errorCode
}
userErrors {
field
message
}
}
}
Once Mollie delivers the asynchronous paid status via webhook after interbank clearing, release the order for warehouse fulfillment.
4. SEPA Compliance Playbook: Pre-Notifications and Checkout Disclosures
SEPA Direct Debit compliance requires merchants to display statutory debtor rights at checkout and issue pre-notifications detailing the collection date, debit amount, Creditor Identifier (CID), and Mandate Reference prior to billing. While baseline regulations specify a 14-day notice period, merchants can legally reduce this window to two days through explicit checkout terms consent.

Legally Reducing the Standard 14-Day Pre-Notification Window via Shopify Checkout Terms
Under standard direct debit operational rules recognized by the European Central Bank, debtors must receive advance notice of an impending debit at least 14 calendar days prior to the due date unless otherwise agreed. For modern e-commerce subscriptions running on weekly or monthly renewal cycles, a 14-day delay renders real-time commerce unworkable.
Direct debit scheme rules explicitly allow the creditor and debtor to agree to a shortened pre-notification period.
To legally enact this reduction:
- Embed the notice terms directly into the checkout consent flow.
- Require customer acceptance before initializing the first payment.
- Compress the pre-notification window to 2 calendar days (or immediate notification for variable billing).
Mandatory Checkout Legal Copy Example:
"By proceeding with this purchase, you authorize (1) [Merchant Trading Name] to send instructions to your bank to debit your account and (2) your bank to debit your account in accordance with the instructions from [Merchant Trading Name]. You agree that the standard 14-day pre-notification window is shortened to 2 calendar days prior to each recurring charge. You are entitled to a refund from your bank under the terms and conditions of your agreement with your bank. A refund must be claimed within 8 weeks starting from the date on which your account was debited."
Automating Transactional Pre-Notification Receipts via Webhooks (Shopify Flow / Klaviyo)
To maintain strict compliance, your system must deliver a transaction receipt prior to debiting the customer’s bank account. This can be automated using Shopify Flow, Klaviyo, or transactional email webhooks:
[ CRON: 48 Hours Pre-Billing ]
│
▼
[ Query Contracts Due in 2 Days ]
│
▼
[ Dispatch Event to Klaviyo / Postmark Engine ]
│
▼
[ Send Email to Customer: Mandate Ref, CID, Amount, Date ]
Every automated pre-notification receipt must contain mandatory data points:
- Creditor Identifier (CID): The legal creditor reference of the billing entity.
- Mandate Reference (UMR): The unique code identifying the specific mandate agreement.
- Due Date (Collection Date): The exact date the debit will be submitted to the interbank rail.
- Debit Amount: The exact sum to be withdrawn (including EUR currency symbol).
- Debtor IBAN Preview: Masked account string (e.g.,
NL** **** **** **4300).
Mandate Creditor Identifier (CID) Management and Mandatory Checkout Disclosures
When configuring SEPA through Mollie, merchants have two choices regarding Creditor Identifiers:
- Mollie’s Shared Creditor Identifier: Mollie acts as the technical collector. The customer's bank statement displays
Mollie Payments / [Your Store Name]. This requires no administrative overhead and is available out of the box. - Dedicated Merchant Creditor Identifier: Enterprise merchants can register for their own CID via their national central bank (such as Deutsche Bundesbank in Germany or De Nederlandsche Bank in the Netherlands). This ensures that only the merchant's legal business name appears on customer bank statements, lowering dispute rates caused by unrecognized charges.
Format of a SEPA Creditor Identifier (ISO format):
Country Code (2) │ Check Digits (2) │ Creditor Business Code (3) │ National Identifier (Up to 28)
[ DE ] [ 98 ] [ ZZZ ] [ 09999999999 ]
Make sure your Shopify checkout UI clearly identifies whichever CID entity will execute the debit to prevent confusion and immediate chargeback disputes.
5. Mitigating Payment Risk: R-Transactions, 8-Week Refunds, and Automated Dunning
Mitigating SEPA Direct Debit payment risk requires automated parsing of ISO 20022 R-transaction error codes—distinguishing transient insufficient fund returns (AM04) from fatal account closures (AC04)—combined with smart dunning cadences. Because European law grants debtors an unconditional 8-week refund window, merchants must delay high-value physical fulfillment until settlement clearing and maintain audit trails to defend against unauthorized dispute claims.

Decoding Critical SEPA R-Transaction Reason Codes (Insufficient Funds, Account Closed, Invalid Mandate)
When a SEPA Direct Debit fails, the customer's bank returns an ISO 20022 R-transaction reason code. Your webhook middleware must parse these codes to trigger the appropriate recovery workflow rather than executing naive, repeated billing attempts:
| R-Code | Return Category | Meaning | Automated Action Required |
|---|---|---|---|
| AM04 | Insufficient Funds | Customer account lacks balance | Trigger dunning retry after 3–5 business days |
| AC04 | Account Closed | Bank account has been permanently closed | Immediately cancel mandate; prompt for new payment method |
| MD01 | Unauthorised Transaction | Mandate missing, invalid, or expired | Cease collections; mandate voided |
| MD06 | Refund Requested | Customer exercised 8-week refund right | Pause subscription contract; trigger churn mitigation flow |
| MS02 | Customer Refusal | Customer instructed bank to reject collection | Pause subscription; dispatch account inquiry |
| AG01 | Restricted Account | Account blocked for direct debits | Prompt customer for alternative credit card or PayPal |
Building an Automated Dunning and Retry Schedule for Failed Subscription Charges
Retrying SEPA Direct Debits requires careful timing. Unlike credit cards—where retrying a failed transaction within hours can succeed if a temporary credit hold clears—SEPA clearing runs on daily interbank clearing windows. Furthermore, European banks often levy return fees for failed debits.
Follow this structured dunning protocol:
[ Day 0: SEPA Return Received (e.g., AM04) ]
│
▼
[ Day 1: Send Friendly Automated Email Notice ] ── Provide instant iDEAL/Card link
│
▼
[ Day 4: Automated SEPA Retry Attempt #1 ] ── Time with standard payroll cycles
│
├─ If Succeeded ──▶ Resume Subscription & Release Order
│
▼
[ Day 5: Retry Fails (R-Code Logged) ]
│
▼
[ Day 6: Switch to Fallback Hosted Payment URL ] ── Request alternative payment rail
│
▼
[ Day 14: Freeze SubscriptionContract in Shopify ] ── Prevent fulfillment leaks
- Do not retry immediately: If a transaction fails with code
AM04, schedule the retry 3 to 5 business days later, ideally timed around the end of the month when European salaries are distributed. - Cap automated debits at two attempts: Never retry a SEPA direct debit more than twice. Compounding bank fees will alienate the customer and risk administrative action from payment processors for high return ratios.
- Deploy hosted fallback links: When a direct debit attempt fails, generate a single-payment checkout session using Mollie's
POST /v2/paymentswithout recurring flags. Send this link to the customer via SMS or email, enabling immediate settlement via alternative rails such as iDEAL, Bancontact, or credit card.
Risk Management Protocols for the 8-Week Unconditional Refund and 13-Month Dispute Windows
SEPA Core Direct Debit affords consumers statutory legal protections under European financial law:
- 8-Week "No Questions Asked" Refund Window: Any debtor can demand a full, unconditional refund from their bank for up to 56 calendar days (8 weeks) after the debit date, as documented under Mollie's direct debit framework. The bank must execute the refund immediately without arbitrating the merchant's commercial terms.
- 13-Month Unauthorized Debit Window: If the debtor claims that no valid mandate was ever provided, the dispute window extends up to 13 months [Mollie Recurring].
Practical Risk Mitigation for Shopify Merchants:
- Fulfillment Hold on First Recurring Orders: For high-value physical subscriptions (e.g., luxury goods, consumer electronics), do not create Shopify fulfillment orders while the transaction is
pending. Wait until the payment status transitions topaid. - Cryptographic Mandate Audit Logs: To defeat unauthorized dispute claims, record and archive the complete mandate creation footprint:
- Sign-up timestamp and client IP address.
- User-agent header.
- The transaction ID (
tr_xxx) of the initial authenticating payment (iDEAL/Bancontact). - The exact legal disclaimer presented to the customer during checkout.
- B2B SEPA Schemes for High-Value Goods: If selling B2B subscriptions, consider the SEPA Business-to-Business (B2B) Direct Debit Scheme. Under the B2B scheme, debtors have no right to a refund once the transaction clears, eliminating the 8-week refund risk. Note that this requires the debtor's bank to register the mandate before processing the first debit.
Conclusion: The Path to Scaled European Recurring Commerce
Scaling a recurring revenue model across Europe without SEPA Direct Debit is like driving with the handbrake engaged. By implementing Mollie’s recurring payments engine alongside Shopify’s subscription architecture, merchants eliminate reliance on credit card rails, tap into dominant domestic banking behaviors, and reduce involuntary churn.
To get started, follow this implementation checklist:
- Ensure your checkout legally shortens the pre-notification window to 2 business days.
- Configure initial mandate capture through instant rails like iDEAL and Bancontact with
sequenceType: "first". - Build a webhook listener to handle asynchronous
pendingtopaidstatus transitions. - Programmatically parse ISO 20022 R-codes to run intelligent dunning routines instead of blind retries.
Executing this technical blueprint gives your store the payments foundation required to scale seamlessly across the European single market.
Bilal Mehmood
Co-founder
Bilal Mehmood is a TkTurners co-founder focused on AI automation, systems integration, and practical operational infrastructure for growing businesses.
Relevant service
Review the Integration Foundation Sprint
Explore the service lane

