How the Magento Open Source shipping carrier integration returns live rates and labels
Magento Open Source ships built-in UPS, FedEx, DHL and USPS carrier integrations that request live rates and create labels through each carrier's account. For a store, this means the checkout can show shipping prices based on the actual cart and destination, and the warehouse can print a label from the order without a separate shipping tool. The flow starts when a shopper enters a delivery address. Magento builds a rate request from the cart contents, the weight and dimensions stored on each product, the warehouse origin address and the units configured for the store. It sends that request to each enabled carrier, receives the available services and prices, and displays them at checkout. When the order is fulfilled, an administrator creates a shipment, and Magento requests a label from the same carrier account.
The store holds the carrier credentials, not DeployOpen and not Magento. Each carrier's section in the store configuration asks for the account details that carrier issues, such as an account number and the API credentials or keys tied to that account. Those credentials determine who is billed for labels, which contracted or negotiated rates apply, and whose tracking data appears in the carrier's systems. Before go-live, the team should decide who owns each carrier account, how credentials are stored and rotated, and who can change the configuration in production. Confirm the exact fields each carrier requires and whether the test and production endpoints are separate settings in the Magento line you are deploying.
Do not assume the carrier coverage, service levels or API behavior from the product name alone. Check them against the release notes for the specific Magento Open Source line you plan to run, because the supported services, country coverage and carrier request formats can change between releases. For the current line, the 2.4.9 release notes are the document to start with. Confirm which services each carrier offers for your origin and destination countries, whether domestic and international label types match what your warehouse needs, and how the integration responds when a carrier API times out or returns an error during checkout. These are the behaviors that most often surprise teams after launch.
Verify the flow end to end in a test environment before any production order is shipped. Use test carrier accounts where the carrier provides them, and place sample orders across the destinations, weights and package sizes you ship most often. Compare the rates shown at checkout with the rates on the carrier invoice, confirm that dimensions and weight units reach the carrier correctly, and print each label format your packing stations use. Record the results as acceptance evidence. If your store later ships through several carriers with rules that go beyond these built-in integrations, that is the point to evaluate a multi-carrier service, and the scope of that decision should be written down before the build starts.
Prerequisites for the Magento Open Source shipping carrier integration
Confirm these items before any carrier settings are entered. Each one changes what the configuration can do later: the release sets the supported stack, the carrier accounts supply credentials, and the origin data and network path decide whether live rates and labels return. Check them in this order so that gaps surface before the build starts.
Supported 2.4.x release line
Choose a 2.4.x release that Adobe still supports at go-live, and plan the upgrade window that follows it. Adobe's released versions page lists 2.4.9 as released on May 12, 2026, and Adobe's lifecycle policy gives 2.4.9 support through May 31, 2029. Support for 2.4.6 ends on August 11, 2026, so a store planned on that line would need an earlier upgrade. Confirm that each carrier module and third-party extension supports the release you select.
Runtime stack at listed versions
Match PHP, database, search, cache, queue, Composer and nginx to the table for your chosen release. For 2.4.9, Adobe's system requirements 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 a store running an unlisted PHP or search build may appear to work but falls outside support. Record each version in your environment inventory before installation.
One carrier account per carrier
Open a carrier account for each carrier you will connect, whether UPS, FedEx, DHL or USPS, and request both production and test access. Test access lets the team validate rate requests and label responses before any live shipment is created. Ask each carrier which credentials, client identifiers and endpoints apply to your account type, and which endpoint the module should use during build. Store production secrets in your approved vault and name an owner for each account.
Shipper address and origin data
Collect the shipper address, origin locations and contact details that each carrier expects on rate and label requests. Confirm with each carrier which address fields must match its account records, since a mismatch can cause rate or label errors. List every warehouse or dispatch point with its country, postal format and default ship-from location. Decide who approves changes to origin data, because one change affects rates and labels for every store view that uses that origin.
Outbound HTTPS from the web tier
Allow outbound HTTPS from every web node to each carrier endpoint, and test the path from the same network segment that serves storefront requests. Firewalls, egress proxies and NAT rules often differ between web nodes and administration hosts, so a test run from a jump server proves little. Ask each carrier for the hostnames and address ranges it publishes, and whether those change. Log failed carrier calls so a blocked endpoint appears as a visible error in the logs.
Setup sequence for the Magento Open Source shipping carrier integration
This sequence takes a self-hosted Magento Open Source store from an installation with carrier modules available to a store that returns live UPS, FedEx, DHL and USPS rates, prints labels and writes tracking numbers to orders. Each step closes with a check the team can run before moving to the next one.
Confirm platform version and carrier modules
The platform engineer confirms the installed Magento Open Source version against Adobe's system requirements for that release, including PHP, the database and the search engine, and checks that the UPS, FedEx, DHL and USPS carrier modules are present and enabled under the delivery methods configuration. Carrier API support changes over time, so the team also confirms that each carrier module is on a release that calls the carrier's current API, including the USPS REST API patch. Done when all four carriers appear as enabled in the admin and the system log shows no module or configuration errors after a cache flush.
Set store origin and measurement units
The store administrator enters the ship-from address in the store information settings and sets the weight and dimension units to match what the carrier accounts expect. Rate requests depend on these values, so a wrong origin postcode or unit setting produces rates that look plausible but do not match the carrier's calculation. Done when a test rate request from the store origin to a known domestic address returns without an address or unit validation error, and the weight shown in the request matches a test product weighed by hand.
Enter sandbox credentials and test rates
The integration owner enters the sandbox account credentials for each carrier in the carrier configuration screens, keeps the test or sandbox mode switch on, and saves each set separately. The team then runs rate requests from the checkout or a test cart for a known address. Done when each carrier returns at least one service with a rate for the test address, and the request and response entries in the carrier log show the sandbox endpoint rather than production. Credential values should be stored in the secrets process your organization already uses, not shared in chat or tickets.
Set allowed services and country lists
The commerce lead chooses which services each carrier may offer, such as ground and expedited options, and sets the ship-to countries for each carrier. Restricting services keeps checkout from offering options your contracts or operations do not support. The team then places test carts with a domestic and an international address. Done when checkout shows only the approved services for each address, carriers are excluded from countries they do not serve, and the allowed list matches the written shipping policy approved by the business owner.
Configure packaging and label format
The fulfillment lead defines the package dimensions, default packing rules and label format for each carrier, including the label size and file type the warehouse printers accept. Packaging defaults affect both dimensional weight on the rate and the box a warehouse packs. The team then creates a sandbox shipment for a test order. Done when a sample label generates with the expected size and format, the package dimensions on the label match the physical test box, and the label prints correctly on the warehouse printer model used in production.
Switch to production carrier credentials
The integration owner replaces the sandbox credentials with production account credentials for each carrier, turns off test mode, and confirms that only named administrators can view or edit the credential fields. The security lead records who holds each carrier account and how credentials are rotated. Done when a production rate request for a known address returns a rate consistent with the account's contracted pricing, and no sandbox endpoint appears in the carrier log. Ask each carrier for its current production onboarding steps and any account approval requirements before this switch.
Verify label and tracking on a live order
The operations lead places a controlled test order, creates a shipment, generates a label and confirms the tracking number is written back to the order and visible to the customer notification. The team uses a low-risk address and checks the carrier's rules for voiding or refunding test labels before generating one. Done when the tracking number appears on the order, the carrier's tracking page resolves it, and the label is recorded against the shipment. Repeat this check for each carrier before the integration is handed to daily operations.
Which Magento data feeds each carrier request
This table maps each Magento data input that a UPS, FedEx, DHL or USPS rate or label request depends on, the team that usually owns the source value, and the check to run before a label is created. Use it to agree data ownership with warehouse, catalog and finance teams before configuration starts, because a missing weight or wrong origin address is the most common reason a live rate or label fails.
| Request input | Where Magento stores it | Data owner | Check before a label is created |
|---|---|---|---|
| Product weight and dimensions | Product attributes on each simple product or child item, plus packaging rules if your warehouse uses them | Catalog team, confirmed by warehouse for physical packs | Every shipped item has a non-zero weight in the unit your carrier account expects, and dimensions are present where the carrier requires them |
| Shipping origin | Stores > Configuration > Sales > Shipping Settings > Origin, one set per store view or website | Warehouse or operations lead | The origin address matches the pickup or dropship location on the carrier account and the postal code is valid for that country |
| Destination address | Order shipping address captured at checkout and stored on the order | Customer data, checked by fulfillment | Country, region and postal code are present and validated, and PO box or military addresses are handled per the carrier's rules |
| Package and declared value rules | Package rules in the shipment and carrier configuration, plus order subtotal or item price for declared value | Warehouse for packing, finance for declared value policy | Each package has a weight within carrier limits and a declared value the finance policy allows, and multi-package splits are set before rating |
| Service codes per carrier | Enabled methods in each carrier's configuration, mapped to allowed services for the origin and destination | Shipping or fulfillment lead, with the carrier account owner | Only services available for the lane and account are enabled, and each code matches a method shown at checkout |
| Carrier account and credentials | Carrier account number and API credentials in the carrier configuration section | Carrier account owner, usually finance or IT | The account number, billing terms and sandbox or production mode match the environment being tested |
| Tracking numbers and label files | Shipment records and the order's shipment tracking, with label files stored by Magento | Fulfillment team, reviewed by operations | Each shipment has one tracking number, the label file is attached to that shipment, and the order status updates after the label is created |
When built-in carrier rates, table rates or a multi-carrier service fits
The built-in UPS, FedEx, DHL and USPS modules fit a store with one shipping origin, carrier-published rates that match the packages you actually ship, and services those modules expose in the admin. You configure them under Stores, Configuration, Sales, Delivery Methods, where each carrier needs its account credentials, origin address, package defaults and allowed services. Before you commit, confirm in your Magento Open Source version which services, package types and label options each module supports, because the built-in list is narrower than most carrier portals. If your catalog is mostly small parcels from one warehouse, this is usually the lowest-effort path.
Table rates and free shipping rules replace live quotes when a flat or banded price is the better commercial answer. Typical cases include regional flat fees, heavy or oversized goods where carrier quotes vary widely, negotiated contract rates that the module cannot read, and promotions that waive shipping above a cart threshold. Table rates are maintained as conditions such as weight, price or destination, so every rate change is a data task that recurs and needs an owner. Free shipping rules sit alongside cart price rules, so promotion logic and shipping logic must be tested together. Neither option gives shoppers live carrier pricing or carrier labels.
A multi-carrier shipping service becomes relevant when the built-in modules cannot cover the operation. Signals include several warehouses or fulfillment sources with different origins that need rate shopping across carriers, service levels the built-in modules do not expose, carrier accounts that differ by region, consolidated tracking across carriers, or returns workflows that the native modules do not handle. A service of this kind adds another system to run, with its own credentials, callbacks, failure handling and contract terms. Ask each provider to separate licensing fees from integration work and to state who maintains the carrier connections when carriers change their APIs.
The choice sets the integration effort, so decide before the build starts. Built-in carrier modules need account setup and test shipments for each carrier. Table rates need ongoing data maintenance. A multi-carrier service needs middleware work, monitoring and vendor management. Before deciding on the USPS module, check the current USPS notices on the retirement of Web Tools and confirm with Adobe whether the REST API patch applies to your Magento Open Source version and how it changes USPS rate and label calls. If USPS calls depend on a retired interface, plan the patch, a test window and a fallback rate method before go-live.
Securing carrier credentials and label data
The carrier integration touches two sensitive assets: the account credentials that buy shipping services and the label data that describes customers and their orders. Each card below covers one control, what to confirm in your installed version, and where it meets the store's wider compliance obligations.
Storing carrier credentials and environments
Carrier account identifiers, keys and passwords are entered in the shipping method configuration in the Magento admin. Confirm in your installed version whether these values are encrypted at rest, where the encryption key is held, and whether saved secrets are masked when someone reopens the form. Keep sandbox and production credentials in separate environment-specific configuration, never in a shared file. Document who can rotate keys when a carrier account changes hands.
Least-privilege access for label staff
Staff who print labels need to create shipments and print documents, and little else. Build a custom admin role limited to the order shipment and label printing resources, leaving tax, payment and carrier settings to administrators. Test the role with a real staff account before go-live, and confirm which admin resources the shipping and print actions require in your version, since the permission tree changes between releases. Review role assignments whenever staff move teams.
Outbound-only network rules
Web and worker nodes only need outbound HTTPS to the carrier rate and label endpoints, plus DNS and any proxy you operate. Block all other egress from those hosts and allow no inbound connections initiated by carriers. Request the current endpoint list from each carrier, because hostnames can change, and retest rate requests and label creation after every firewall or proxy change.
Logging label creation and voids
Label creation, voiding and tracking changes need an audit trail that shows who acted, on which order, and when. Confirm which of these events the installed version writes to logs by default, then forward web, admin and worker logs to your central platform with retention set by your policy. Reconcile voided labels against carrier reports on a schedule, because a void that fails silently leaves a charge and an open tracking number.
Shipping data as personal data
Recipient names, addresses, phone numbers and order references are personal data under the GDPR. The store needs a documented lawful basis, a retention period for label data, and a clear record of each carrier's role in processing. Limit what reaches logs, exports and error reports. Shipping fields fall outside cardholder data, but labels are printed from admin pages that sit near payment code, so agree the PCI DSS scope with your assessor before the integration goes live.
Content Security Policy and patching
Adobe's developer documentation states that Adobe Commerce and Magento Open Source support Content Security Policy headers from 2.3.5, and that from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Check that the policy still allows the scripts your carrier screens need. Adobe recommends upgrading every patch cycle to stay secure and PCI compliant, so schedule patch reviews and confirm the handling of credentials and label data in your installed version.
Common carrier integration failures and how to fix them
This table lists the carrier integration failures teams hit most often on a self-hosted Magento Open Source store, with the likely cause, the first diagnostic step and the usual fix for each. Work through the rows starting with checkout rates, because several later symptoms share the same origin and configuration. Confirm version-specific USPS and carrier behavior against the release notes for your installed version and the carrier's own documentation before changing production settings.
| Failure | Likely cause | Diagnostic step | Fix |
|---|---|---|---|
| Rates missing at checkout | The carrier is not enabled for checkout, no allowed methods are selected, the origin country or postcode is blank, or products have no weight so the rate request is incomplete. | Check Delivery Methods for each carrier, then run a test request from the admin and read var/log/system.log and exception.log for the carrier's error. | Enable the carrier for checkout, select the services to offer, complete the shipping origin, set product weights, then flush the cache with bin/magento cache:flush. |
| Carrier authentication errors after moving from sandbox to production | Production credentials were not entered, or sandbox keys, account numbers or the sandbox gateway setting were left in place after go-live. | Compare each carrier's mode, gateway URL and credential fields with the values issued for production, then check the logs for authentication or unauthorized responses. | Replace every sandbox credential and gateway setting with the production values issued by the carrier, save, flush the cache and place a test shipment with a low-risk order. |
| Labels fail for weight or dimension reasons | A product weight is zero or missing, the weight unit does not match what the carrier expects, or package dimensions are absent or outside the service limits. | Open the failed shipment's error message, then compare the weight and dimension attributes of the products in that shipment with the weight unit set in locale options. | Correct product weights and dimensions, confirm the store weight unit, define a default package where the carrier requires dimensions and split oversized shipments into packages the service accepts. |
| Country or service mismatches | The service code is not offered for the destination, the store allows countries the carrier does not serve, or the destination region is missing from the address. | Review Ship to Specific Countries and the allowed services for the carrier, then run test requests for each destination country that appears in recent orders. | Limit the carrier to countries and services it supports, add a fallback method for other destinations and require complete addresses at checkout. |
| Timeouts from the web tier | Web nodes cannot reach the carrier endpoints because of outbound firewall or proxy rules, or the PHP or nginx timeouts are shorter than the carrier's response time during peak checkout. | Test outbound HTTPS from each web node to the carrier endpoint, then check php-fpm and nginx timeout settings and the logs for connection or read timeout errors. | Open outbound access for each carrier endpoint from every web node, align PHP and nginx timeouts with the carrier's expected response time and consider a fallback rate when a request fails. |
| USPS requests failing after the Web Tools change | The USPS integration still points to the retired Web Tools interface, the store is running a version that lacks the required patch, or the credentials were issued for the old service. | Check the installed Magento Open Source version against the release notes for the USPS change, confirm the patch is applied and review logs for USPS HTTP or authentication errors. | Apply the Adobe-documented patch for your version, update the USPS credentials and endpoint settings for the current USPS API, then retest rates and labels before reopening checkout. |
| Tracking numbers not returning to orders | The tracking number was added with the wrong carrier code, the label was created outside the store, or the shipment was never saved with the tracking record. | Open the order's shipments tab and confirm the tracking number and carrier code, then search logs for errors raised when the label was created. | Create shipments and labels from the admin or the carrier integration so the tracking record is written to the shipment, select the matching carrier code and add missing numbers manually where needed. |
What drives the effort and duration of a carrier integration
The effort of a carrier integration is set by the size and shape of your shipping model before any code is written. The first factors to count are the number of carriers and carrier accounts you will connect, since each UPS, FedEx, DHL or USPS account carries its own credentials, service levels, negotiated rates, label settings and test cycle. The number of warehouses and origin addresses matters just as much, because every origin affects rate requests, transit estimates, label generation and return addresses. Ask for a written list of accounts and origins before you ask for a timeline, and check whether each origin ships from a different country or currency set. Product data quality is the factor teams most often underestimate. Live rates depend on weight and dimensions stored against each product and each configurable child. Missing or wrong values produce rates that are too low, rejected requests or labels with the wrong package size. Plan a data audit of the catalog, including bundles, kits and any products shipped in a separate box. Custom packaging rules, such as dimensional packing, box selection, hazardous or restricted items and customer-specific label requirements, add logic that must be designed, tested and documented. Destination coverage is the next driver. Each destination country adds customs forms, duty and tax treatment, restricted-destination checks, postal code rules and service availability that differ by carrier. The number of storefront and admin flows that depend on shipping also grows the work: checkout estimates, cart and product page estimates, admin order creation, label printing, returns, order emails, tracking pages and any ERP or warehouse system that reads shipment data. Each flow needs its own test cases. Confirm with the carrier which services you need for each country before you size the build. The Magento version you are moving to can change the scope. Adobe's upgrade guide recommends upgrading on every patch cycle to stay secure and PCI compliant, and it names customizations, extension count, third-party integrations and coding practices as the drivers of upgrade effort. If you upgrade Magento at the same time as the carrier work, shipping code that overrides core classes or depends on third-party shipping extensions has to be reviewed against the target release. Run Adobe's Upgrade Compatibility Tool against your code to find those dependencies early. No duration should be treated as a planning figure until it comes from a written scope. A scope should list carriers, accounts, origins, countries, shipping flows, data cleanup tasks, customizations and the upgrade path, with acceptance tests for each. Ask any partner to show which of these factors they have assumed and what changes the estimate if one of them grows.
Questions buyers ask before hiring help with carrier shipping
How much does a Magento carrier shipping integration cost?
The cost follows from the written scope, and DeployOpen does not publish a price list. The main drivers are how many carriers you connect, how many services and packaging types each carrier must support, how many origin locations you ship from, how many custom rules you need (such as surcharges or product-level restrictions), and how many storefront and checkout paths must be tested. Ask the partner to split the quote into discovery, configuration, custom code, testing and go-live support so you can see who is paid for each part. Carrier account fees and API access are set by each carrier and are not part of the implementation fee, so confirm them directly with each carrier.
Is a carrier integration a one-time project or ongoing work?
The core build is one-time, but some work recurs. The initial setup covers carrier account connection, origin addresses, service mapping, packaging rules, label output and testing. Recurring work includes watching for carrier API and service changes, refreshing credentials, handling new surcharges or services, and applying Magento patch releases that touch shipping code. Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, so shipping code needs retesting on that rhythm too. Carrier-side changes can arrive without much notice, so plan for periodic review. Ask whether the quote includes a support period after go-live, and what a retainer covers if you want ongoing monitoring and upgrades.
How long does it take to set up UPS, FedEx, DHL or USPS?
No duration is stated here because it depends on the scope and on how quickly your team supplies inputs. DeployOpen agrees timelines in the written scope before work starts. Duration rises with the number of carriers, the number of services you offer, custom rules such as dimensional weight handling or multi-warehouse origin logic, the state of your product data (missing weights and dimensions are a frequent cause of delay), and carrier account approval times, which your partner does not control. A single carrier with standard rates and labels usually moves faster than a multi-carrier setup with custom rules. Ask for a phased plan that lists dependencies, and confirm sandbox and production approval timing with each carrier before you commit to a go-live date.
What do we need to provide before a shipping integration starts?
Your store team provides the accounts, data and test material the build depends on. Prepare these before kickoff:
- Carrier accounts: API credentials for test and production for each carrier you connect
- Origin data: warehouse or dock addresses, contact details and pickup or drop-off settings for each origin
- Product data: accurate weights and dimensions for each SKU, including bundles and configurable products
- Sample shipments: representative packages from your current process, with their weights, sizes and destinations
- Test orders: a set covering domestic, international, free shipping and any return or split-shipment cases you run
- A decision owner: one named person who can approve carrier settings and sign off test results
Missing product data and delayed account access are the most common blockers, so confirm both early.
Can our internal team implement Magento carrier shipping without a partner?
Yes, a team with Magento and PHP experience can configure the built-in carrier modules, since UPS, FedEx, DHL and USPS ship with Magento Open Source. The decision depends on three things: whether the team has time, whether it has the skills for the less common parts, and whether it has the test capacity. Standard setup is mostly admin configuration, while custom rules, checkout changes and multi-carrier logic need code in custom modules that follow the platform's PSR-4 module structure. Consider upgrades as well. Adobe's upgrade guide names customizations and third-party integrations as drivers of upgrade effort, so custom shipping code adds work at every patch cycle. Decide by comparing skills, capacity and who will maintain the code after go-live.
What should a written quote for carrier integration include?
A useful quote is a written scope that a second engineer could build from. It should list:
- Carriers and services: which carriers, which services, and which origin and destination countries
- Rate methods: live carrier rates, flat rates, table rates and free shipping rules, with the rule logic stated
- Labels: how labels are created, printed and stored, and who handles returns
- Custom work: each custom module, theme change or script, with its purpose
- Testing: sandbox use, test orders, sample shipments and who signs off
- Deliverables: configuration records, documentation and handover sessions
- Assumptions and client inputs: the items in the list above, with owners and due dates
- Exclusions: carrier fees, carrier approvals and any work outside the listed carriers
- Timeline: milestones with dependencies
- Support terms: post-go-live period and the change request process
DeployOpen's engagements are fixed-scope, so these items are agreed in writing before work starts.
Does Magento Open Source need a multi-carrier shipping service?
Not always. The built-in integrations cover live rates and labels for UPS, FedEx, DHL and USPS, and table rates and free shipping rules handle many simpler cases. A third-party multi-carrier service is worth evaluating when you need carriers outside those four, consolidated rate and label management across many carriers, or features the built-in modules do not provide. Confirm the supported services and countries for each built-in carrier against Adobe's documentation for your release, because coverage varies by carrier and region. Also confirm the current USPS connection method and any patch your version requires, since USPS connectivity has changed and the required steps depend on your release. Make the decision after you list the carriers and services your business needs.
Which Magento version and PHP versions should we confirm before shipping work?
Confirm your target release against Adobe's system requirements before design starts. Magento Open Source 2.4.9 was released in May 2026, and its requirements 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. Support windows also matter: Adobe lists end of regular support as May 31, 2029 for 2.4.9 and May 31, 2028 for 2.4.8. If your store runs 2.4.8-p5, its requirements differ (PHP 8.4 or 8.3, with Varnish 8 listed). Carrier SDKs, modules and any custom shipping code must also work with your chosen PHP version, so test them in a staging environment that matches production.
How DeployOpen scopes, builds and supports your carrier integration
DeployOpen plans, configures, customizes and supports Magento Open Source shipping carrier integrations inside your own infrastructure. Each engagement starts with a written, fixed scope that names the carriers, services, packaging rules and environments involved, so you know what is built and handed over before work begins.
How we scope
- We confirm which carriers, services and countries your store ships to before any build work starts.
- We record your account setup, rate and label needs, and the Magento release line your store runs on.
- We document table rates, free shipping rules and packaging logic in the written scope, with an agreed change process for later additions.
How we build
- We configure the built-in UPS, FedEx, DHL and USPS integrations in staging, then test live rates and label generation against carrier sandboxes.
- We check the USPS integration against the Web Tools retirement and the REST API patch your release line requires.
- We customize rate logic and checkout display through standard modules, keeping changes within Magento's documented extension structure.
How we hand over
- We deliver test evidence covering rate requests, label output, tracking updates and failure paths for each carrier you use.
- We document credentials locations, configuration settings, cron dependencies and rollback steps for your operations team.
- We walk your administrators and developers through the configuration so they can maintain rules after handover.
How we support
- Ongoing support, carrier API updates and patch testing are available under a retainer agreed in writing.
- We test each Magento patch cycle against your carrier configuration before it reaches production.
- We confirm whether a multi-carrier service or a third-party shipping platform is needed as your volume and destinations change.
