Which PCI DSS SAQ does a self-hosted checkout actually need?
The checkout design, meaning who handles card data and where it travels, determines which self-assessment questionnaire applies, not the platform brand. A merchant running Magento Open Source, WooCommerce, Saleor, Medusa or Sylius can land on a short questionnaire or a full Report on Compliance depending on whether the store's own servers, scripts and forms ever touch the primary account number. The PCI Security Standards Council (PCI SSC) maintains PCI DSS, and the current active version is v4.0.1. The SSC does not enforce compliance or impose penalties. Your payment brands and acquirer decide which validation level applies to you and run any enforcement, so confirm your obligations with your acquirer before you choose a design.
Start by mapping every point where card data is entered, posted or stored. A redirect or iframe payment page hosted by the provider usually keeps the card form off your servers, but the store page that embeds it still runs your scripts, and those scripts can affect the security of the payment page. A direct post or a self-built card form puts your application in the path of cardholder data, which generally widens the questionnaire and the set of controls you must evidence. Ask your payment provider which questionnaire it expects for your integration, and record the answer with the integration version, because a theme or extension update can change the data path.
DeployOpen prepares the systems, controls and evidence that a validation depends on, including hosting configuration, script inventory, change records and network segmentation notes. DeployOpen does not issue the Attestation of Compliance, and certificates are not accepted as validation. The Qualified Security Assessor or the merchant's completed self-assessment questionnaire, with its Attestation of Compliance, is the document your acquirer will request. Before engaging a partner, ask which SAQ they expect your design to produce, which evidence they will hand over, and who signs the attestation on your side.
How redirect, iframe, direct post and self-built forms change scope
With a full redirect, the shopper leaves the store at checkout, enters card details on the payment provider's hosted page, and returns to the store with a result. The store's servers never receive the card number, so this design typically points to the lightest questionnaire category, provided the store has no other path that handles card data. Scope still depends on what the store does around the redirect.
- Card data path: The card number, expiry date and security code are entered only on the provider's domain, so they stay out of the store's logs, caches and databases.
- Return handling: The store should act on the provider's signed result or server-to-server notification, and it should confirm the exact method in the provider's documentation.
- Scripts on the checkout page: The store's own checkout template still loads scripts, and those scripts must be inventoried and controlled.
- Hosting and hardening: Web servers, the platform and plugins can still be in scope if they could affect the security of the redirect flow, so ask the acquirer where the boundary sits.
Confirm the expected questionnaire with your acquirer, and ask your QSA, where one is involved, to check that the data flow diagram matches the live checkout.
An iframe or embedded payment field loads the provider's form inside the store's checkout page. The shopper types card data into fields served from the provider's origin, and the store's code is meant to handle only a token. Because the store's page hosts the frame, the page itself becomes part of the payment picture. Any script that can read or alter that page could affect the payment flow, which is why these designs often carry more scope than a full redirect.
- Frame origin: The provider's frame loads from its own domain, so the store must control which parent pages are allowed to embed it.
- Page scripts: Analytics, tag managers and chat widgets on the checkout page can alter the payment page, so each one must be inventoried and approved.
- Content Security Policy: On Magento Open Source, Content Security Policy headers are supported from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on payment pages, as Adobe's security documentation explains.
- Theme and template changes: Checkout template and theme edits can break the frame or expose the page, so they need a documented review before release.
- Provider requirements: The provider's integration guide sets the exact fields and scripts it expects, and it should confirm that card data stays out of your page's DOM.
Ask the provider and your acquirer which questionnaire applies to this exact integration, and ask for that answer in writing before the build.
With direct post, the shopper's browser submits card data to the store's own server, which then forwards it to the processor. Card data crosses the merchant's application, so the store's servers, logs, error handlers and plugins are part of the cardholder data environment. This design generally carries a heavier questionnaire category than a redirect or iframe, and it is hard to justify unless there is a specific reason a hosted or embedded option cannot meet the business need.
- Server handling: The application receives the card number and security code in a request, so it must not log, cache or store them, including in debug output.
- Infrastructure in scope: Web servers, load balancers, web application firewalls and database hosts that process the request are typically within the assessed environment, so confirm the boundary with your QSA.
- Logging and monitoring: Application logs, proxy logs, performance traces and error reports must be scrubbed, because one verbose logger can bring card data into scope.
- Payment modules: Third-party modules that handle the post are software you must keep patched, monitored and assessed.
- Change frequency: Every release of the application, plugins and infrastructure can alter the scope, so the evidence needs to be refreshed on a recurring basis.
Before you choose this design, ask your acquirer and QSA whether a hosted or embedded option meets the need, because the choice changes the questionnaire and the evidence set.
A self-built card form is a page the merchant designs and hosts to collect card numbers, expiry dates and security codes directly, then sends them to a processor through an API. This design places the store's own front end and its scripts in the card data path. It usually leads to the most extensive questionnaire, the SAQ D category, because the merchant handles cardholder data across its own environment. Few stores should build this without a QSA-led scope review.
- Front-end code: Scripts that read the card fields are in scope, so every third-party library and tag must be controlled and checked for unauthorized change.
- Payment page script management: The payment page must be protected against unauthorized script changes, and the standard's requirements on payment page scripts need a detailed scope discussion with a QSA.
- Secure development: Custom code that touches card data needs secure development practices, testing, code review and timely patching.
- Evidence burden: Each applicable requirement needs evidence that it operates, so the effort recurs for as long as the store takes card data this way.
- Hosting and monitoring: Hosts, logs and monitoring tools that touch the card path extend the assessed environment.
Ask the QSA for a written scope statement that lists every host, script and service touching the card fields before any build begins.
Which PCI DSS requirements the checkout must satisfy and how to configure them
This table maps the PCI DSS v4.0.1 requirements that matter most for a self-hosted checkout to what the store must do and how Magento, WooCommerce or a headless build should be configured. Read each row as a question your assessor will ask, then check whether your checkout design actually answers it.
| Requirement or control | What the store must do | How to configure it on Magento, WooCommerce or headless builds |
|---|---|---|
| 6.4.3 script management on payment pages | Inventory every script that loads on the payment page, confirm its business need and authorize it, and make sure it is integrity-checked or otherwise controlled | Keep a written script inventory per payment page, remove tag manager entries no one owns, and use Content Security Policy script-src rules so only approved origins run |
| 11.6.1 change detection on payment pages | Detect unauthorized changes to HTTP headers and payment page content that affects the card data form, and alert personnel | Deploy file integrity and page change monitoring on checkout templates, and in headless builds monitor the checkout bundle and its hosting origin |
| Content Security Policy headers | Restrict which scripts, frames and form targets a browser may use on pages that handle cardholder data | Magento Open Source supports CSP headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages; WooCommerce and headless builds need headers set at the web server or CDN |
| Requirement 1 network security controls and Requirement 2 secure configurations | Segment the cardholder data environment from other hosts and remove vendor defaults and unneeded services | Place the database, payment connectors and admin interfaces on restricted network segments, and document which systems are in scope |
| Requirement 6 secure development and patching | Keep platform, extensions and libraries on supported versions and apply security patches in a defined window | Track end of support dates: Magento 2.4.6 regular support ended August 11, 2026 (Adobe lifecycle policy); WooCommerce, WordPress and Node dependencies need a named patch owner |
| Requirement 7 and 8 access control and authentication | Limit access to cardholder data and admin functions by role, and require strong authentication for administrators and remote access | Separate admin accounts from staff accounts, enforce multi-factor authentication on the admin panel and hosting consoles, and review access quarterly |
| Requirement 10 logging and monitoring | Log access to system components and cardholder data, and review those logs | Forward web server, admin and checkout logs to a central store the platform team cannot silently edit, and alert on admin logins and configuration changes |
| Twelve principal requirements under six goals | Use the 12 principal requirements as the index for the Attestation of Compliance and for the self-assessment questionnaire you select | Map each configuration above to its principal requirement in one workbook so the evidence set matches the questionnaire your payment acquirer requires |
Which open-source platforms fit a low-scope checkout
The platform decides how much of the checkout your team controls, and that decides how much card data and script risk lands in your environment. Each platform below offers a different path to a redirect, iframe or API-driven payment flow, so the choice of platform and the choice of payment integration should be made together.
Magento Open Source
Magento Open Source is licensed under OSL-3.0, and 2.4.9 is the current stable line, with Adobe's system requirements listing PHP 8.5. Checkout scope depends on the payment extension you install, so confirm whether the provider's hosted fields or redirect pages keep card entry off your servers. Self-managed stores typically use Varnish for full-page caching, while cloud-hosted Adobe Commerce uses Fastly, so confirm which cache layer sits in front of payment pages. Content Security Policy runs in restrict mode by default on payment pages from 2.4.7, which helps control which scripts can run there.
WooCommerce on WordPress
WooCommerce is licensed under GPL version 2 or later and 11.2.1 was published on October 9, 2026. Because it runs as a WordPress plugin, every payment gateway and theme script loads inside the same site, so a single outdated plugin can alter the checkout page. Confirm which gateway runs the card form, whether it is a hosted redirect or embedded fields, and who maintains that gateway's script loading. High-Performance Order Storage keeps orders in dedicated tables, which matters for where order data sits but not for card scope on its own.
Saleor API-first checkout
Saleor is a headless commerce API licensed under BSD-3-Clause, with 3.23.42 published on October 16, 2026. In an API-first design, your storefront calls the commerce API, so the team building the storefront decides where card fields are rendered and how payment is submitted. If your storefront collects card numbers directly and posts them to the API, the storefront and its hosting fall inside cardholder data handling, which is the design most likely to raise your questionnaire type. Ask the integration partner which payment app handles tokenization and whether it returns a hosted page or a token only.
Medusa with Enterprise materials
Medusa is MIT licensed, except for materials covered by its Enterprise Edition license, and v2.21.2 was published on September 28, 2026. Before you commit, list every module in your build and confirm which fall under the Enterprise license, because licensing terms affect what you can host and modify. As with other headless builds, the storefront team controls the card form, so the payment provider's tokenization method and script loading determine your scope. Document the storefront's script inventory as part of the build, not after launch.
Sylius with Symfony
Sylius is licensed under MIT, and v2.3.1 was published on October 14, 2026. Sylius is a PHP framework that gives your team the code for checkout templates and payment flows, so your developers decide whether card data ever reaches your application. That control is useful for keeping scope low, but it also means your team owns any custom card form and its script management. Confirm the payment plugin your partner selects returns a hosted or tokenized result, and that your team can document each script on the checkout page.
How hosting and third-party scripts can push a store out of its SAQ
The SAQ answer is not fixed by the checkout design alone. Whether a merchant's servers, hosting stack, CDN, tag managers and plugins can affect the security of the payment page decides the scope, and a store that looks like SAQ A on paper can land in a heavier questionnaire once the rest of its environment is counted. A compromised script on a page that collects card data is the clearest example: if a third-party tag, a CDN-served file or a plugin can alter what the shopper types into a payment field, the page is in scope regardless of who hosts the card form. Reviewers ask the same question about each script: can it read or change the payment page, and who controls its source?
Hosting and administrative access belong in the same conversation. Confirm which systems hold the code that renders the checkout, who can deploy to them, whether the admin panel and its accounts are reachable from the internet, and where the server-side code path handles card data even briefly, such as a proxy, a logging layer or a custom payment module. Each of these can bring a system into the cardholder data environment or make it a connected system that needs its own controls. Ask your hosting provider and your implementation partner to document data flows and access paths in writing, and ask your acquirer which of them they consider in scope before you choose a questionnaire.
The practical step is to map every script, container, extension and administrative path that the checkout page depends on, then mark each as part of the payment page, a connected system or outside scope. That inventory, not the marketing claim of a hosted payment form, is the evidence an assessor or acquirer will test. Plan the controls for the items you cannot remove, including script inventory and change detection on the payment page, and confirm with your acquirer and a qualified assessor how the relevant PCI SSC PCI DSS page requirements apply to your design before any build or hosting contract is signed.
What assessors ask for and which component produces it
This table maps each item an assessor typically asks for in a PCI DSS self-assessment of a self-hosted store to the component that produces it. Read it as a checklist: if a row has no owner in your team or provider, that evidence gap will surface during validation. Certificates and badges from vendors are not accepted as validation, so the completed SAQ, its Attestation of Compliance and the underlying records are what count.
| Evidence item | Component that produces it | What to confirm |
|---|---|---|
| Completed SAQ and Attestation of Compliance | Merchant (signs), with the QSA or internal reviewer where required | Which SAQ type matches your checkout design and that the AOC is on the current PCI SSC template |
| Network and data flow diagram | Solution architect with the hosting provider's network team | Every path that card data or the payment page touches, including CDN, WAF and logging |
| Inventory of payment page scripts and authorization | Storefront developer, with a named approver in the merchant's change process | Each script's source, purpose, owner and sign-off, kept current with every theme or module change |
| Change detection records for payment pages | Monitoring tool or file integrity service running on the storefront | Alerts are generated, reviewed and tied to tickets, and the tool covers the pages in scope |
| CSP configuration export | Web server or platform configuration, such as the Magento CSP settings or headers set at the reverse proxy | The exported policy matches the scripts in the inventory and runs in enforcing mode where required |
| Platform patch and version records | Platform operator or DeployOpen-style implementation partner, with the release notes for the running version | The platform (for example Magento Open Source 2.4.9 or the current WooCommerce release) and its PHP, database and extension versions are on supported branches |
| Access reviews and admin account records | Operations lead with the identity system, reviewed on a set schedule | Who can change checkout code, payment settings and hosting, and that review evidence is dated and signed |
| Service provider contracts and responsibility matrix | Legal or procurement, with each hosting, payment and agency provider | Each provider's PCI DSS responsibilities are written down and their own attestations are on file |
What tooling alone does not satisfy
A hardened platform and a well-chosen checkout design are necessary, but they do not settle SAQ eligibility on their own. The cards below cover the places where teams assume a tool or a vendor has taken over an obligation that stays with the merchant.
A CSP header is not a script inventory
Content Security Policy headers restrict which scripts a browser may run, and Adobe documents CSP support in Magento Open Source from 2.3.5, with restrict mode on payment pages from 2.4.7. A header limits sources but does not record which scripts are loaded, who owns them, or why they are authorized. Build and keep a written inventory of every script on checkout pages, with an owner and a business reason for each, and check that the policy matches it. Confirm the scripts that extensions and tag managers add at runtime, not only those in the theme.
Hosted pages do not remove site obligations
A redirect or iframe payment page moves card data entry to the provider, which reduces the scope of your own environment. It does not remove responsibility for the pages you still serve, including the checkout shell, shipping and billing forms, and any script that can read or alter the surrounding page. Your own checkout pages stay in scope for the controls that govern them. Ask your provider which pages and scripts fall outside its responsibility and document that split in writing.
The SAQ still needs the acquirer's view
The Self-Assessment Questionnaire and its Attestation of Compliance are completed by the merchant, but the payment brands and acquirer decide which validation applies to your business. Enforcement and validation requirements are set by those parties, not by the PCI SSC. Confirm the SAQ type and validation level with your acquirer before you answer the questionnaire. Ask whether they accept a particular checkout design as out of scope and what evidence they expect each year.
Customized approach needs a documented argument
PCI DSS v4.x allows the customized approach for entities with robust security and risk management, meeting a stated objective in a different way than the defined approach. It is not a shortcut around a requirement. Expect a documented, risk-based analysis that shows how the objective is met, how it is monitored, and who reviews it. Confirm with your assessor whether a customized control is acceptable for your validation type before you build it.
Lagging upgrades open lifecycle gaps
Platform and runtime versions reach end of support on fixed dates, and a checkout that runs an unsupported release no longer receives standard security fixes. Adobe lists August 11, 2026 as the end of regular support for Magento Open Source 2.4.6, and later 2.4.x lines have later dates. Track end-of-support dates for the platform, PHP, database, and cache components in your checkout path. Ask your partner for a patch schedule that keeps these components within supported versions.
How to scope the checkout before choosing a design
This sequence fixes the rules, the card data paths and the scripts on payment pages before a checkout design is chosen, so the SAQ type and the evidence behind it follow from facts rather than assumptions. Each step closes with a record that the next step depends on.
Confirm acquirer and payment brand rules
The merchant asks its acquirer and payment provider in writing which PCI DSS validation level, self-assessment questionnaire type and reporting cadence apply to its channel and volume. The PCI SSC does not enforce compliance, so the payment brands and the acquirer set these obligations. Done means a written statement from the acquirer naming the expected SAQ type and any extra requirements the provider attaches to its payment page integration.
Map where card data touches the store
The store owner, with the development team and the hosting provider, draws every path a card number, expiry date or security code could take: the browser, the storefront server, the order database, logs, backups, error reporting and any third-party script. The team also lists which components could affect the security of the cardholder data environment, such as the hosting account and administrative access. Done means a data flow diagram signed off by the engineering lead, with each path marked as touching card data or not.
Choose the checkout design
Using the data flow map, the team compares redirect, iframe hosted by the provider, direct post and a self-built card form against the requirements the acquirer confirmed. Each design implies a different questionnaire and a different set of controls on the store, so the choice must be recorded with its reason. Done means a design decision record that names the chosen integration, the expected SAQ type and the party that will confirm that type.
Inventory scripts and plugins on payment pages
The team lists every script, tag, extension and theme component that loads on the cart, checkout and payment return pages, including those added by marketing, analytics and fraud tools. Each item is assigned an owner, a source and a business reason, and any item that is not needed on those pages is removed. Done means a current script inventory that matches what the browser loads, verified by a crawl of the live checkout in a test environment.
Configure content security policy and change detection
Engineers set a content security policy that allows only the sources named in the inventory, and they deploy a monitoring control that detects unauthorized changes to payment page content and scripts. For self-managed Magento Open Source stores, the platform documents CSP support from version 2.3.5, with restrict mode on payment pages by default from 2.4.7, but the team must confirm the settings in its own build. Done means a tested policy in report-only mode followed by enforcement, plus alerts that have been triggered and resolved in a test.
Collect evidence for each requirement
The team gathers the artifacts an assessor will ask for: the data flow diagram, the design decision record, the script inventory, CSP configuration exports, change detection alert logs, access reviews for hosting and admin accounts, and patch records for the platform and extensions. Each artifact is dated and stored with a named owner. Done means an evidence index that maps each artifact to the requirement it supports, so gaps are visible before the assessment begins.
Have the SAQ or ROC completed by the right party
Based on the confirmed SAQ type, the merchant completes the official self-assessment questionnaire, or engages a Qualified Security Assessor to produce a Report on Compliance, and signs the matching Attestation of Compliance. Implementation partners prepare systems and evidence, but they do not issue the attestation. Done means a signed Attestation of Compliance submitted to the acquirer, with the questionnaire answers traceable to the evidence index.
How much work does PCI DSS SAQ scoping add to a self-hosted store?
What drives the cost of PCI DSS scoping for a self-hosted store?
The biggest driver is checkout design. A store that hands card entry to a payment provider's hosted page carries a much smaller validation burden than one that collects card data on its own forms, because the scope of the cardholder data environment shrinks with each change. Other drivers are the number of third-party scripts and plugins loaded on payment pages, the hosting model, and what your acquirer or payment brand requires for validation. Cost has three parts: internal staff time, external help for architecture and configuration, and any Qualified Security Assessor work if your validation level requires a Report on Compliance. Ask any partner for a quote that lists each part separately and states which items are one-time and which recur each year.
Can our team complete PCI DSS scoping without outside help?
Often yes, if you have engineers who know the storefront, the hosting stack and the payment integration, and someone who can read the PCI DSS requirements and the official self-assessment questionnaire. The harder part is proving the result: you need documented data flows, evidence of script control and payment page change detection, and a current Attestation of Compliance signed by the right party. Teams that lack this experience usually get the design right on paper but miss gaps in plugins, caching layers or admin access. An outside partner can review the design and prepare evidence, but the merchant remains responsible for the validation and for the decisions behind it.
What does our team need to provide for a scoping engagement?
Expect to supply the material that describes how card data moves through your store. The usual list includes:
- Documentation from your payment provider describing the checkout integration, including whether card fields are hosted by the provider or by your store
- Architecture diagrams for the storefront, payment flow, hosting, caching, search and any connected systems
- An inventory of scripts, tags and plugins loaded on checkout and payment pages
- Read access to the hosting environment, deployment pipeline and admin panel, along with a named technical contact
Your acquirer or payment brand may also ask for prior validation records. Confirm the full list in writing before work starts.
How long does PCI DSS scoping take for a self-hosted store?
No fixed duration applies to every store. The timeline depends on how many payment paths exist, how many scripts and plugins touch checkout, how much hosting and access evidence is missing, and whether validation requires a Report on Compliance or a self-assessment questionnaire. The written scope and the agreed deliverables set the schedule, so ask for milestones tied to specific outputs such as the data flow diagram, the script inventory and the signed attestation. Also check the timing of your acquirer's deadlines, because they, not the PCI Security Standards Council, decide when validation is due.
Does changing the checkout design reduce the scope of PCI DSS?
Yes, in most cases it is the most effective lever. When the customer's card data is entered into a payment page hosted by the provider, through a redirect or a tightly controlled iframe, your systems typically never store, process or transmit cardholder data. That generally points to a shorter self-assessment questionnaire, such as SAQ A, which applies only if the page controls described in the questionnaire are met. A direct post or a self-built card form keeps your servers in closer contact with card data and usually leads to a longer questionnaire with many more requirements. Confirm the eligibility criteria against the current PCI DSS v4.0.1 questionnaire and your provider's documentation before redesigning checkout.
Who signs the Attestation of Compliance for a self-hosted store?
The merchant signs the Attestation of Compliance, not the PCI Security Standards Council or the consultant who helped prepare the evidence. The AOC is attached to either a Self-Assessment Questionnaire or a Report on Compliance, and a Qualified Security Assessor completes the ROC when that route applies. Certificates are not recognized as validation, so do not accept a badge or certificate in place of the signed AOC. The payment brands and your acquirer decide which validation you must submit and to whom, so confirm that route with them before the work starts.
Does PCI DSS scoping need a Qualified Security Assessor?
It depends on your validation level, which your acquirer or payment brand sets. A self-assessment questionnaire can be completed by the merchant, while a Report on Compliance must be completed by a Qualified Security Assessor. Even when a QSA is not required, a second reviewer with assessment experience can reduce the risk of an incorrect scope decision. Ask any partner whether they will perform the validation, prepare evidence for your assessor, or only advise, because these are different deliverables with different costs.
What DeployOpen does and does not do for the SAQ
DeployOpen plans, implements, hardens and documents the checkout, the script controls and the hosting that an SAQ answer depends on. In practice that means choosing the payment integration pattern with you, building or configuring the payment page so that card data stays with the provider, setting up the script inventory and change detection around payment pages, locking down the servers and containers that host the store, and writing down how each control is operated and by whom. We also prepare the evidence an assessor or your acquirer will ask for, such as configuration baselines, change records, network diagrams and the responsibility matrix that separates your controls from your payment provider's. Where a requirement belongs to someone else, such as the provider's hosted page or a third-party script vendor, we document that boundary instead of assuming it.
DeployOpen does not issue Reports on Compliance, Self-Assessment Questionnaires, Attestations of Compliance or certifications. Only your acquirer or the payment brands determine which validation applies to you, and only a Qualified Security Assessor or you, as the merchant, complete and sign the PCI SSC templates. Engagements are fixed-scope: the systems in scope, the deliverables, the evidence set and the timeline are agreed in a written quote before work starts. Ask any partner, including us, to put the checkout pattern, the SAQ you expect to file and the excluded components in writing before the quote is signed, and to confirm with your acquirer that the same SAQ applies.
How DeployOpen works on this
DeployOpen starts from the checkout design, because that choice sets which self-assessment questionnaire applies and which controls the store must evidence. We plan, implement, harden, document and support the self-hosted store inside your own infrastructure, and we prepare the evidence your assessor or acquirer will ask for, without issuing any attestation ourselves.
How we scope
- We map every page and script that touches card data, from checkout to payment callbacks and third-party tags.
- The written scope names the checkout pattern, the applicable SAQ and the requirements we are asked to evidence.
- We confirm with your acquirer or payment provider which questionnaire and validation level they expect before work begins.
How we build
- We implement the agreed payment page pattern, such as a provider-hosted redirect or iframe, on your chosen platform.
- We lock down script loading, Content Security Policy headers and access to payment pages, then test them against the written scope.
- We run security testing of the storefront and checkout and record the findings, fixes and retests in a shared log.
How we hand over
- You receive configuration records, architecture diagrams, data flow maps and a script inventory for the in-scope pages.
- Runbooks cover patching, change control for scripts and tags, and how to re-check payment page integrity after upgrades.
- We document which evidence belongs to you, your payment provider and your assessor, so responsibilities are explicit at handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover platform upgrades, security patches and re-testing when a payment provider changes its integration.
- Scope changes, such as a new payment method or a new checkout flow, are agreed in writing before the work starts.
