Magento Open Source Payment Services integration: what it connects and what to confirm first
A team running a self-hosted Magento Open Source store that needs card and wallet payments should plan to connect Adobe Payment Services through the Commerce Services Connector. That choice shapes the rest of the project, because the connector's version, its support for Magento Open Source, its install method and any Adobe account onboarding steps determine what the team builds and who must act. Confirm all four in Adobe's current documentation before anyone scopes effort or signs off a design. If the documentation leaves gaps, ask Adobe directly and record the answer with the date you received it, since vendor guidance can change between releases.
The integration connects four areas of the store. The first is the storefront checkout, where card fields and wallet buttons appear to shoppers. The second is the Magento admin, where payment methods are enabled, configured and tied to store views. The third is the connector module itself, which is added to the Magento codebase as a module and must follow the structure Adobe documents for modules. The fourth is the Adobe side: the account, credentials and environment settings that link the store to Adobe Payment Services. Each area needs an owner on the client side, and the sandbox data space Adobe provides for testing should be confirmed for your account type before the team plans test cycles.
Several checks should happen before design work starts. First, confirm that the connector version supports the Magento Open Source release line you run, and check the matching system requirements for PHP, the database, search, cache and message queue components. Second, check your release line's end of regular support date in Adobe's lifecycle policy. Adobe lists May 31, 2027 for 2.4.7, so a store on that line should decide whether an upgrade must land before the connector work is finished. Third, confirm that the connector's scripts and frames work under the restrict-mode Content Security Policy that Adobe applies to storefront and admin payment pages from 2.4.7.
DeployOpen plans and builds the integration inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. The work starts with the written checks above, followed by a scope that names the connector version, the environments, the payment methods to enable and the test cases to run in the sandbox. DeployOpen then installs and configures the module, tests checkout flows, and documents the setup for your operations team. Most engagements are fixed-scope. When you ask for a quote, request separate line items for planning, module build, sandbox testing, handover and any ongoing support retainer, so you can see which costs are one-time and which recur.
Which Magento Open Source stack and accounts the payment integration needs
The payment integration depends on three layers that must agree before configuration starts: the platform stack Adobe supports for your Magento Open Source release, a Payment Services account tied to your legal entity, and network paths from your store to the provider. Check each layer early, because a gap in any one of them delays the connector setup and the sandbox tests that follow.
Platform stack for release 2.4.9
Adobe's system requirements for Magento Open Source 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. Adobe supports only the listed combinations, so an unlisted database version, a different PHP build or a host outside Linux x86-64 places the store outside supported territory. Confirm each component against the current requirements page before you provision servers or containers, and record the exact versions in your change log.
Adobe Payment Services account and onboarding
The connector cannot process live payments until the merchant account is onboarded with Adobe Payment Services and linked to the store. Ask who owns the legal entity record, which people need administrator roles in the provider portal, and how sandbox and production credentials are issued and kept separate. Plan the onboarding lead time with the provider, since it runs outside your build schedule and may gate the go-live date. Keep credentials in your secrets manager and out of configuration files committed to source control.
HTTPS and certificates
Storefront and admin pages that collect payment details should run over HTTPS with a certificate that browsers trust, and the connector's return and callback addresses must use the same public hostname. Confirm which certificate authority your organization uses, who renews certificates and how expiry is monitored, because an expired certificate stops checkout. Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 the policy runs in restrict mode on payment pages, so retest the payment fields after any header change.
Outbound network access to provider endpoints
The web nodes and any worker hosts need outbound connections to the Adobe Payment Services endpoints, and those connections must pass through your proxy and firewall policy. Request the current endpoint list from the provider in writing, because hostnames can change and an allowlist copied from another project may be stale. Confirm whether rules are set per environment so that sandbox and production traffic follow separate paths. Run connectivity tests from the same subnet and egress route production uses.
Store country and tier availability
Adobe offers the payment integration in Standard and Advanced tiers, and availability depends on the country where the store and the merchant entity operate. Confirm the base country of the store and of each storefront against the current tier availability information before you choose a tier. A country mismatch can block onboarding or limit the payment methods on offer. Record the answer with the date you checked it, and ask the provider to confirm it in writing for multi-country stores.
How Standard and Advanced tier availability by country shapes the build
The tier a merchant can use for Adobe Payment Services depends on the merchant's country and the countries where the store sells. Settle this question before the checkout design, the wallet list and the payment method configuration are fixed, because each of those depends on the answer. No tier or country matrix was available when this page was written, so every statement about availability needs confirmation from Adobe for your specific merchant entity and target markets. Record the answer in the design document as a dated assumption, with the name of the Adobe contact who gave it.
The tier determines which wallets, card fields and local payment methods the Commerce Services Connector can present at checkout in each market. A single Magento Open Source installation that serves several countries may show different payment options per country, so decide early whether those countries will run as separate websites or as store views under one website. That choice affects the payment method settings in each scope, the checkout templates and the test plan. Each combination of tier, country, wallet and payment method becomes a row in the test matrix, and sandbox results only count for the combinations the sandbox actually reproduces.
Ask Adobe for written answers covering each target country. Confirm which tier applies to your merchant entity and whether the tier is set per merchant account, per store or per sales region. List the wallets available in each country and tier, including Apple Pay, Google Pay and PayPal, and the card field options, including how 3D Secure is handled. Ask which local payment methods are offered per country, with their currency and settlement conditions. Ask whether the sandbox data space offers the same tier and country combinations as production. Ask what changes if you add a country or move to a different tier, what happens to saved cards and stored tokens in that case, and what each tier costs, who pays for it and whether it recurs.
Keep the answers in a country matrix that the team updates when the business enters a new market or changes its sales regions. Quote the Adobe fees from Adobe's own agreement, because DeployOpen's implementation fee is separate and follows from the written scope. Implementation effort rises with the number of countries, wallets, card field variants and local payment methods, since each one adds configuration, testing and support work. Ask Adobe for the written tier and country terms before you sign the scope, so that the build plan and the Adobe commercial terms agree on what the store will offer.
How to set up Adobe Payment Services on Magento Open Source in order
This sequence takes a self-hosted Magento Open Source store from a confirmed release line to a sandbox order that has been captured and refunded through Adobe Payment Services. Each step ends with a check your team can record, so the configuration is verified before any live payment is accepted. Adobe's connector documentation for your exact 2.4.x release remains the reference for module names, commands and settings.
Confirm the release line and server stack
Start by fixing the Magento Open Source release line you will run, such as 2.4.8 or 2.4.9, and checking it against Adobe's system requirements for that exact version. Adobe supports only the listed combinations of PHP, database, OpenSearch, cache, message queue, Composer and web server, so compare your current servers against that list and record any gaps. Confirm with Adobe which Payment Services tier and features are available in your country before you commit to a design. Done means a signed-off compatibility record that names the release, each component version and the tier you will use, and that record is checked against the running servers with a version report.
Provision the sandbox account and data space
Ask the merchant or platform owner to create the Adobe account and a sandbox data space that is separate from production, then confirm who holds administrative access to each. Record which people can view, rotate and revoke sandbox credentials, and keep that list with the project documents. Confirm in Adobe's documentation how the data space affects card data handling and PCI DSS scope, since the answer shapes your network and logging decisions later. Done means a working sandbox login for the named owners and a stored list of access holders. A test login that succeeds and an access list that matches it are your checks.
Install and enable the connector for the release
On a non-production copy of the store, install the Commerce Services Connector using the steps Adobe documents for your target 2.4.x release, and do not improvise module names or commands from older guides. Run the standard Magento setup steps that follow an installation, including the database upgrade and cache flush, then confirm the module is enabled. Keep the Composer changes in version control so they can be reproduced on each environment. Done means the module reports as enabled on the build server. A module status listing that shows the connector as enabled, with no errors in the setup output, is the check.
Configure credentials for each environment
Enter sandbox credentials only on development and test environments, and enter production credentials only on the production store, so no environment can send live requests by accident. Store the values in the secret mechanism your team already uses for deployment, and restrict who can read or change them in the admin panel. Confirm with Adobe which endpoint each environment must call and whether any webhook or callback address needs to be registered, since that address must reach your store. Done means each environment shows its own credential set and a test transaction reaches the sandbox endpoint. The check is a request log entry showing the sandbox endpoint, and a mismatch between environments is a failure.
Enable chosen payment methods and wallets
In the admin panel, enable only the card and wallet methods that the business has approved, and set the title, sort order and any country or currency limits for each. Confirm with Adobe the domain, device or account steps needed for each wallet, since some wallets require verification before they will display at checkout. Do not enable methods that the business has not approved for the sandbox, so test results match what will go live. Done means the storefront checkout in the sandbox store view shows each approved method and hides the rest. The check is a checkout page where each enabled method appears and each disabled method does not.
Set storefront and admin payment pages
Configure the storefront checkout and the admin order creation pages so the payment fields and scripts load from the sources Adobe specifies. From Magento 2.4.7, Content Security Policy runs in restrict mode by default on payment pages, so each script, frame and connection source the connector needs must be allowed explicitly in the policy configuration. Review this with the front-end and security team and keep the changes in version control. Done means both pages load the payment fields without errors. The check is a browser console with no Content Security Policy violations on checkout and on the admin order creation screen.
Run a sandbox order through capture and refund
Place a test order on the storefront with a sandbox card and one wallet, then confirm the authorization in the Adobe sandbox. Create an invoice to capture the payment, and then create a credit memo to refund it, both from the admin order screen. Check that the callback or webhook arrives at your store and that the application log records the authorization, capture and refund with matching identifiers. Record each result in the test log so the sequence can be repeated after upgrades or changes. Done means the order record shows the invoice and the credit memo, the sandbox dashboard shows the same transaction, and the logs contain entries for each event.
How the payment integration changes your PCI DSS scope
The payment integration decides how much of your Magento Open Source store falls inside the cardholder data environment, and therefore how much PCI DSS work you carry. PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, and also to entities that could affect the security of that environment. The PCI Security Standards Council states that this includes merchants, processors, acquirers, issuers and service providers. Before you choose a design for Adobe Payment Services, map where card data enters the store, where it moves between systems, and where it rests, including logs, backups and support tooling.
Hosted card fields keep card entry inside the provider's frame, so your store receives a token instead of the primary account number. This reduces the systems PCI DSS reaches, but it does not remove your obligations. You still control the payment pages, the JavaScript that loads on them, and the admin accounts that can change them. A design that handles card data directly on your own servers brings more systems, more requirements and more evidence into scope. Ask Adobe and your acquirer to confirm which fields are hosted, whether any card data touches your web or database tiers, and how tokens are stored. Adobe documents Content Security Policy support from 2.3.5 and restrict mode by default on payment pages from 2.4.7, so test those settings on your payment pages to confirm what they block in your environment.
PCI DSS v4.x lets you meet each requirement through the defined approach or, for entities with mature security and risk management, the customized approach, which meets the stated objective in a different way. PCI DSS v4.0.1, published on 11 June 2024, is the only active version since PCI DSS v4.0 was retired on 31 December 2024. The standard is organized into 12 principal requirements grouped under six goals. Most integration projects start with the defined approach for the payment pages and servers, because it is simpler to document. A customized approach needs a documented objective, a targeted risk analysis and ongoing monitoring, and it takes more assessor time to accept. Decide per requirement, and record the decision before build work starts.
The validation route depends on your assessment type. A Self-Assessment Questionnaire (SAQ) on the official PCI SSC template ends with an Attestation of Compliance (AOC), and a Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA) also ends with an AOC. The PCI SSC does not enforce compliance. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Your acquirer or the brands will tell you which validation applies. A compliance certificate is not accepted as validation. Also note that the PCI SSC ran a request for comments on PCI DSS v4.0.1 from 3 June to 20 July 2026 and had announced no release date for a new version as of October 2026, so plan against v4.0.1.
DeployOpen prepares systems, controls and evidence for the assessment, including scope diagrams, data-flow records, segmentation configuration, access reviews and patching records. DeployOpen does not issue an Attestation of Compliance or a Report on Compliance. Those come from your assessor or your validation process. Before scoping the build, ask your acquirer which validation applies, request the written scope from DeployOpen, and confirm with Adobe which payment flow the Payment Services integration uses in your country and tier. Those answers determine the SAQ type or the QSA engagement you will need, and they should be settled before the integration design is frozen.
Which store data maps to which provider fields
This table lists the Magento store entities that the Payment Services connector reads or writes, the provider object each one most likely corresponds to, who owns the value, and whether Magento keeps a copy. The provider field names were not part of the research for this page, so the last column names what to confirm in Adobe's connector documentation before you finalize the mapping. Use it as a checklist for the integration design review.
| Store data | Provider object (to confirm) | Owner | Stored in Magento and what to confirm |
|---|---|---|---|
| Orders | Transaction linked to the order reference | Both sides set the value | Order record is kept in Magento. Confirm which order identifier is sent as the payment reference and where the provider transaction ID is saved. |
| Invoices | Capture or settlement event against the order | Store owns the value | Invoice is created in Magento. Confirm whether capture runs at invoice time or at order placement, and how partial invoices are reported. |
| Refunds and credit memos | Refund transaction referencing the original transaction | Both sides set the value | Credit memo is kept in Magento. Confirm how refunds reference the original transaction and whether partial refunds are supported. |
| Customer accounts | Payer or customer reference, if one is passed | Store owns the value | Customer entity is kept in Magento. Confirm which customer identifiers the provider receives and whether it stores a profile or token for them. |
| Billing and shipping addresses | Billing and shipping details on the payment request | Both sides set the value | Order addresses are kept in Magento. Confirm which address fields are sent and whether wallet-supplied addresses overwrite the Magento address. |
| Currency and amounts | Transaction currency and amount in the provider's format | Both sides set the value | Order and base currency are kept in Magento. Confirm which currency is authoritative when display and base currencies differ, and how rounding is handled. |
| Store view and scope | Merchant account or sandbox data space per configuration scope | Store owns the value | Settings are kept in Magento configuration. Confirm whether credentials can be set per website or store view and which data space each scope uses. |
| Payment method | Method type, wallet and card brand or last digits | Provider owns the value | Method code is kept in Magento. Confirm which card fields are returned and that full card numbers never reach Magento servers. |
| Payment status | Authorization, capture, refund and failure states | Provider owns the value | Order and transaction status are kept in Magento. Confirm how each provider state maps to Magento order states and whether webhooks or polling update them. |
Security settings to harden for the payment connection
These controls decide whether the payment connection keeps card data out of your own systems and whether storefront and admin traffic stays protected. Each card names a setting to confirm before go-live and a check to repeat after changes. Review them again on every Adobe patch cycle, because configuration drifts as the store, its extensions and its hosting change.
Separate sandbox and production credentials
Issue distinct API credentials for the sandbox and production environments, and never copy one set into the other. Confirm where each set is stored, typically in a secrets manager or in environment-specific configuration outside the codebase, and who can read it. Check that sandbox credentials cannot process live transactions, and rotate production values when staff with access change roles. Confirm with Adobe's current payment setup documentation which credential fields each environment requires.
Least-privilege admin roles
Create admin roles that can edit payment configuration without holding rights to unrelated areas such as user management, system settings or refunds, unless one person genuinely needs both duties. Limit the number of accounts that can change payment methods, API settings or stored connection details. Require named accounts with multi-factor authentication for every administrator, and review role assignments on a fixed schedule. Export the role matrix so auditors can see who can change the payment configuration.
Content Security Policy on payment pages
Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. Confirm your version and that the policy is enabled in restrict mode. Review custom scripts, third-party tags and extensions that load on checkout, since they may need an allowed source added or may be blocked. Test checkout in staging after every policy change.
Caching rules that exclude payment and account pages
Self-managed stores can use Varnish as the full-page cache, and the rules must never store checkout, payment, cart, customer account or other personalized responses. Confirm the Varnish configuration excludes those paths and any response that carries session data. Test with a logged-in customer and an open checkout session, and confirm cache purges cannot expose one shopper's page to another. Adobe's 2.4.8-p5 requirements list Varnish 8 among the supported components.
TLS on every call
Serve the storefront and admin over HTTPS, and encrypt every request between the store and the payment service. Confirm the connection validates certificates against your trust store and that checkout pages load no mixed content. Include internal hops that carry payment or session data, such as the proxy in front of the store and links to cache, search and session services, even where traffic stays inside your network. Scan the public endpoints externally and retest after certificate or proxy changes.
Logs that exclude card data
Configure application, web server, proxy and payment logs so they never record full card numbers, security codes, authentication data or complete request bodies from payment calls. Confirm debug logging is off in production, and apply the same rule to any log shipped to a central platform. Check access controls and retention on log storage, since logs are often copied to locations with weaker controls. Test by running a sandbox transaction with test card numbers and searching every log for them.
How to test the integration before go-live
The test plan should prove that every payment path your store uses works in the sandbox data space before a live card is processed. Start by listing the transaction states your checkout can reach, then map each one to a test case with an expected result, a named tester and a place to record evidence. Begin with successful and declined authorizations, because they exercise the core flow between the Magento Open Source store, the Commerce Services Connector and the payment service. Confirm that sandbox credentials, merchant identifiers and webhook endpoints point only to the sandbox data space, and keep a written record of which store views and payment methods each case covers.
Next, test the lifecycle after the order is placed. Run partial and full captures against orders with different totals, then issue refunds and voids on both captured and uncaptured transactions. Check that order status, invoice records and payment transaction entries in Magento match what the payment service reports. Wallet flows need their own cases. Test each wallet you plan to offer on the browsers and devices your customers use, and confirm which wallets are available in your country and on your tier, since availability differs by market. Where your tier offers 3D Secure or another authentication challenge, test passed, failed and abandoned challenges separately. If a feature is not included in your tier, record that decision so the scope is clear to reviewers.
Failure paths matter as much as success paths. Simulate webhook or callback failures by blocking the endpoint, returning errors or delaying delivery. Then confirm that the store reconciles the transaction later and does not create duplicate orders or capture the same payment twice. Test checkout under timeouts, including a slow authorization response, a browser session that drops after the customer submits payment, and a return to the store after the order was already processed. For each case, define the message the customer should see and the operational step that follows, such as who checks the payment dashboard and how a stuck order is released or escalated.
Results carry over to production only if the sandbox mirrors production closely. Compare PHP and Magento versions, extensions, Content Security Policy settings, cache layer, queue and cron configuration, store views and payment method settings between the two environments, and record every intentional difference. Test evidence also serves compliance work. Keep test records, screenshots and logs in your change management system so that your assessor can see how cardholder data flows were verified and how they were scoped. PCI DSS v4.0.1 is the only active version. The PCI Security Standards Council does not enforce compliance, so ask your Qualified Security Assessor or your SAQ provider which records they expect before testing begins.
Why payments fail after the connector is enabled
This table lists the failures most often seen after the Commerce Services Connector is enabled on a self-hosted store, with the likely cause, the check to run and the fix for each. Work through the rows in order, because a wrong environment or an unsupported PHP version can hide problems that appear later. Most failures trace to settings that differ between sandbox and production, or between the web tier and the external services it calls.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Payment method missing at checkout | The tier or country setting does not cover the shopper's country, so the method is hidden. | Compare the billing country and the shopper's country with the tier and country list in the connector configuration. | Enable the method for that country or choose a tier that supports it. Confirm availability in Adobe's current documentation first. |
| Credentials rejected or no transactions recorded | Sandbox credentials are used in production, or the reverse, after switching environments. | Confirm the selected environment matches the credential set and the data space it was issued for. | Replace the credentials with the matching set, flush the configuration cache and run a test transaction. |
| Connector errors or missing options | The PHP or extension version falls outside the supported matrix for the installed 2.4.x release. | Compare PHP and extension versions with Adobe's system requirements for the exact 2.4.x patch in use. | Move PHP to a listed version, or upgrade to a 2.4.x release that supports the PHP version already in place. |
| Timeouts when the shopper pays | The web tier cannot make outbound HTTPS calls to the payment provider's endpoints. | Test outbound connections from each web node, including DNS resolution, proxy settings and egress firewall rules. | Allow the required provider endpoints through egress rules or the proxy, and confirm PHP and cron use the same proxy. |
| Provider scripts or payment frames blocked in the browser | Content Security Policy directives omit the provider's script, frame or connect sources. | Open browser developer tools on checkout and look for CSP violation messages that name provider hosts. | Add the provider's sources to the policy for the matching scope, test on staging, then confirm checkout loads in production. |
| Stale prices, buttons or payment fields | Full-page cache, such as Varnish on self-managed installs, serves checkout or cart pages from before the change. | Check cache status headers on checkout pages and whether the cache was flushed after saving the settings. | Flush the cache after configuration changes, exclude checkout pages from caching and verify in a clean browser session. |
| Provider notifications never update orders | The callback URL uses a host or port the provider cannot reach, or a firewall or WAF blocks the callback path. | Confirm the callback uses the public base URL over HTTPS, then review provider event logs for failed deliveries. | Correct the base URL, open the callback path at the edge and replay a test event to confirm the order status changes. |
| Wrong amount, currency or store view | Allowed currencies, base currency or store view scope differ between the connector and the storefront. | Compare allowed currencies, base currency and each store view's scope in the admin with the connector settings. | Align settings at the scope where they apply, reindex and flush the cache, then place a test order in each store view. |
Questions buyers ask before hiring help with payment integration
What determines the cost of a payment services integration?
Cost depends on the scope you define, and no price is given here. The main drivers are the payment methods you enable (cards, wallets and local methods), the number of store views and currencies that each need checkout configuration, the PCI DSS approach you choose, any custom checkout or payment rule work, and how deep the testing goes.
One-time costs cover planning, configuration, custom code, testing and go-live support. Recurring costs cover ongoing support, upgrades and any retainer you add later. Ask every provider for a quote that lists each driver as a separate line item with its assumptions. DeployOpen works on fixed-scope engagements, so the quote follows a written scope that you approve before work starts.
How long does a Magento Open Source payment integration take?
The timeline depends mainly on how much of the scope is new work and how quickly your inputs arrive. No duration is given here. Length is set by the number of payment methods and store views, whether connector setup and sandbox data spaces are already in place, the country-specific availability of Standard and Advanced tier features, the PCI DSS approach and the evidence it requires, custom checkout work, and the testing cycles for each method.
Delays usually come from waiting on account access, product owner decisions about payment rules, or a security contact who is hard to reach. Ask for a schedule that shows each dependency and the client input it needs.
What do we need to provide before payment integration work starts?
The client must provide access and decisions early. Adobe account access is needed to configure the connector and data spaces. Environment access covers staging, production and the infrastructure where Magento Open Source runs. Product owners must define payment rules, such as which methods appear in which markets, refund policies and failed-payment handling. A security contact must answer questions about hosting, logging, key handling and incident response, and review the evidence.
You should also name a project lead who can approve scope changes in writing. Confirm Adobe account roles and any country-based tier limits with Adobe before you sign a scope, because both depend on your account and location.
Can our internal team integrate payment services without outside help?
Yes, an internal team can do this alone if it has the skills and time. The work needs Magento module and configuration experience, familiarity with payment flows and callbacks, server and PHP administration, and someone who can read PCI DSS requirements and map them to your environment.
Many teams find the evidence to be the hardest part: documenting scope, configuration and test results so an assessor can follow them. A partner helps when internal staff are committed to other releases, when the project needs an independent security review, or when you want a documented handover. DeployOpen plans, implements, hardens and documents these systems in your own infrastructure, and can be engaged for the full build or for specific parts.
How does the PCI DSS approach change payment integration scope?
The PCI approach you choose sets how much of your environment falls into scope. The PCI Security Standards Council maintains PCI DSS, and the payment brands decide which entities must validate. The current active version is v4.0.1, published 11 June 2024, and v4.0 was retired on 31 December 2024.
PCI DSS v4.x lets you meet each requirement through the defined approach, or through the customized approach for entities with strong risk management. How card fields are delivered changes what touches your servers, so confirm that design with Adobe. Validation comes from a Qualified Security Assessor (through a Report on Compliance) or a Self-Assessment Questionnaire with an Attestation of Compliance. DeployOpen prepares systems, controls and evidence, but it does not issue attestations, and your assessor decides the outcome.
Do store views and currencies change payment integration effort?
Yes. Each store view and currency pair can change which payment methods appear, how amounts are displayed and which accounts or data spaces are used, so the effort grows with the combinations. Plan a matrix of markets, languages, currencies and methods before configuration starts. Then decide which combinations need full testing and which can be verified by sampling.
Confirm per country whether Standard or Advanced tier features are available, because tier availability can limit which methods you can offer in a given market. Ask any provider to show this matrix in the quote, with each row tied to a test case.
What testing should happen before we take live payments?
Testing should cover every payment method, currency and store view in your matrix, plus the failure paths. Use sandbox data spaces to verify authorization, capture, full and partial refunds, voids, declines, timeouts and payment notifications. Check that the storefront, checkout and admin pages send only the data you expect.
From 2.4.7, Adobe runs Content Security Policy in restrict mode by default on payment pages, so confirm that policies do not block the payment scripts. Record every test result as evidence for your assessor. Run a final rehearsal on production-like infrastructure, agree a rollback plan, and ask for the test plan and acceptance criteria in writing before work starts.
How do we get a fixed-scope quote for payment integration?
Start with a written scope that lists the payment methods, the market and currency matrix, the PCI DSS approach, any custom checkout or payment rule work, the testing depth and the environments involved. Share your current Magento Open Source version and hosting details so the provider can check compatibility with Adobe's documented requirements.
DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, so the more precise the scope, the more precise the quote. Ask for assumptions, exclusions and the client inputs each milestone depends on, and whether ongoing support or upgrades should be priced as a separate retainer.
How DeployOpen works on this
DeployOpen plans, builds and hands over the payment integration inside your own infrastructure, on a self-hosted Magento Open Source store, including the connection to Adobe Payment Services. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as a retainer.
How we scope
- The written scope names the store version, hosting environment, and payment methods in each country you sell in.
- Scoping confirms which Adobe Payment Services tier each target country supports, verified with Adobe before design begins.
- Engagements are fixed-scope, and the PCI DSS scope decision is recorded in the written scope document.
How we build
- Connector setup and sandbox data space configuration are built and tested in non-production environments first.
- Wallet and card field behavior is tested against the sandbox for each payment method and browser in scope.
- Custom modules and themes follow the documented PSR-4 module structure, with checkout changes reviewed before release.
How we hand over
- Documentation covers configuration values, credential ownership, sandbox and production settings, and the card data flow diagram.
- Evidence for your PCI DSS assessor is prepared: configuration records, change history and test results.
- Independent assessors issue the compliance reports and attestations that your PCI DSS review requires; DeployOpen does not.
How we support
- Retainers cover ongoing support, upgrades and continuous testing of the payment connection, agreed in writing.
- Re-check the country and tier matrix when Adobe changes availability, and after each Magento patch release.
- Scope changes after a PCI DSS revision, such as v4.0.1, are assessed and agreed in a change request.
