The Packstation problem is usually described as a checkout problem: German shoppers need a field for their DHL Postnummer and most stores do not have one. That is half of it. The other half is that the locker address has to survive the trip from the checkout through the order management system and the warehouse to the carrier booking, as structured data, or the label still fails. This page is the field-by-field setup, from the DHL API backwards, for Shopify, Shopware, Ongoing WMS and any other warehouse system. The background, what the Postnummer is and why DHL insists on it, is in DHL Packstation and the Postnummer explained.
Short answer: Work backwards from what DHL's Parcel DE Shipping API accepts. A Packstation destination is a separate consignee type identified by a locker ID, with a 6 to 10 digit post number, the name, postcode and city. Everything upstream has to deliver those fields: a station picker built on DHL's Location Finder API (which returns the station number and ID), a dedicated Postnummer field validated at checkout, one agreed convention for where the number lives in the order (address line 2 or the company field), and a warehouse and shipping-platform mapping that passes the station and the number as separate fields rather than a flat street line. Then place a real test order before go-live.
Start from the DHL API, and work backwards
DHL's Parcel DE Shipping API (v2) defines specific recipient address types for lockers and post offices. Its documentation: "The delivery of shipments to a 'Packstation' or 'Postfiliale Direkt' needs to be implemented. For these services a 6-10 digit postal number ('PostNummer') is provided. Specific types of addresses have been defined for the recipient: 'Packstation' and 'Postfiliale'." A Packstation destination is identified by the locker ID attribute, with the post number, name, city and postal code alongside it.
Two more DHL APIs complete the picture. The Location Finder Unified API returns DHL service points by postcode or coordinates; Packstations come back with type "locker", the keyword "DHL Packstation", the station number as keywordId, a location ID, opening hours and closure periods; initial access is 500 calls per day, upgradable on request. The Parcel DE Postnumber API validates a first name, last name and post number and returns true or false, with the reason when false (number not present, blocked or not yet activated; or the name differs from the registered one). It requires a DHL business customer contract and manual approval, and DHL restricts it to preparing shipments.
So the data the checkout must produce is: station number (and ideally the location ID), post number, recipient name, postcode, city. Everything below is about keeping those five fields intact.
The checkout: a picker, a field and a validation
Station picker. Call the Location Finder with the shopper's postcode, show the Packstations with their opening hours, and let the shopper choose. Write the address yourself in DHL's format: "Packstation" plus the three-digit number in the street line, postcode and city from the station record. Never ask the shopper to type "Packstation 123" into a street field; that is where most broken orders come from.
Postnummer field. A dedicated field, labelled "DHL Postnummer", required when a Packstation is selected, validated as 6 to 10 digits before the order is placed, with one line telling the shopper where to find it (the Post & DHL app or the customer card). If you hold a DHL business contract, call the Postnumber API with the name and number and refuse the order on a false answer, showing the reason: the most common ones DHL's own FAQ lists are a shopper using a partner's or roommate's number, an unfinished identity verification, and a nickname or title that does not match the registered name.
Express checkouts. Shop Pay, PayPal, Apple Pay and Google Pay skip custom fields. One of the Shopify apps built for this, Packstation & Paketshop PLUS, auto-corrects Packstation addresses entered via Shop Pay and express checkouts after the order is placed; whichever tool you use, make sure express orders are caught, because they are the ones that reach the warehouse unvalidated.
Carrier guard. A Packstation address must route to DHL. DPD, GLS and Hermes cannot deliver into a DHL locker, so a rate rule that lets another carrier win on price for a Packstation order creates a guaranteed failure. The German 3PL FLEX Logistik lists "wrong carrier selection" among the four most common failure modes, next to treating the Postnummer as optional, flat address export, and incorrect service codes that the API accepts and the sorting hub rejects.
Shopify: where the Postnummer lives
Shopify's checkout has no Postnummer field, so every integration borrows one of two existing fields, and the choice has to match what your label tool reads:
- Address line 2. DHL's own Post & DHL Shipping app for Shopify instructs: street and house number "Packstation 598", and the post number in the additional-address field.
- Company. Address Validator's Packstation rule prompts the shopper to "enter the customer number in the 'Company (optional) or customer number' field", and the Packstation Lookup app's default mapping writes the Postnummer to the company field with the station name in address line 2.
Both work with DHL's label tools as long as the convention is consistent. Pick one, document it, and set every downstream mapping to it. The apps that do the picker and the validation in Shopify's checkout extensibility include Packstation & Paketshop PLUS (Location Finder search, Postnummer validation, address written in DHL's format; free for 25 lookups a month, then $5 to $20 a month), BB DHL Packstation in Checkout, Address Validation Ninja and endereco.
Shopware: the plugin convention
Shopware's checkout can carry a dedicated Packstation input. The Repertus Packstation extension gives the shopper a special input mask, lets them search Packstations and post offices by postcode and pick on a map, stores the post number in the company name field for ERP compatibility, and fills the street field with "Packstation" or "Postfiliale" automatically so the address is mail-compliant without ERP changes. A recent version adds "Validate Packstation / post office number via DHL API", which checks the station number and location type when the address is saved or the order is placed. The company-field convention is the one to carry downstream.
Ongoing WMS: no locker field, so the convention has to hold
Ongoing WMS has no field for a locker. Its order object carries the consignee's Address, Address2 and Address3 lines, PostCode, City and CountryCode, plus a service point code described as "code of the service point that the customer wishes to pick up the package at" and the transporter's service point ID and code. A Packstation therefore travels in Ongoing as a convention: "Packstation 123" in Address, the post number in Address2, and the station's code in the service point field.
Two mappings decide whether that convention survives.
- Into Ongoing. Ongoing's Shopify integration maps the Shopify shipping address line 1 to Address, line 2 to Address2, first and last name to Name and phone to the phone fields, and reads service points from supported checkout apps' order metadata into the service point fields. The company field is not in the documented mapping. So if your checkout puts the Postnummer in the company field, check with Ongoing how it reaches the order; if it puts the number in address line 2, it arrives in Address2 by default.
- Out of Ongoing. Ongoing books carriers through a shipping platform (its documentation lists more than 40, Sendcloud, EasyPost and Shipmondo among them), and the DHL locker consignee type is built in that platform's mapping, not in Ongoing. The warehouse operator's job in Ongoing is to confirm the carrier and send the booking; whether the platform turns "Packstation 123" plus a numeric Address2 into DHL's locker type has to be verified per platform with one test order.
Any other WMS: the failure mode and the fix
FLEX Logistik describes the generic failure in one sentence: "The OMS exports the address in a flat format, the WMS receives it as a standard street address, and the carrier API rejects the label request because the address type is not flagged as a Packstation delivery." Its fix is that the Packstation designation is identified at the OMS and transmitted as a distinct address class, with the station number and the Postnummer each in their own mapped field in the carrier call.
Where a distinct class is not possible, the German ERP reybex documents the convention most label tools detect: a Packstation address is recognised when the street field contains "Packstation" and a three-digit number (case does not matter); the Postnummer is passed in address line 2, must contain only digits, keeps leading zeros when passed as text, and has leading and trailing spaces removed. byrd applies the equivalent rule at release: a valid Postnummer is 6 to 10 digits in the company name or address-addition field, and shipments without one are blocked.
So the generic recipe is: a locker type with locker ID and post number as separate fields wherever the system allows it; otherwise the exact string convention above, enforced at checkout and preserved unchanged at every hop.
The pre-launch test
Before telling German customers the option exists, run the chain end to end: place a real order to a real Packstation with a real Postnummer, let it flow through the OMS and the warehouse, and confirm the label passes DHL's API validation. Then place one through an express checkout, and one with a wrong post number, and confirm both are caught before the warehouse sees them. FLEX Logistik's checklist ends on the same instruction, and it is the only test that proves the mapping rather than the checkout.
What changes with registration-free Packstation delivery
DHL piloted Packstation delivery without a DHL account from July 2025 with about 20 shops and has announced a nationwide rollout for 2027, most likely for commercial shippers; the shopper picks the station in the checkout and receives a pickup code by email. For the integration that removes the post number from the required fields for those orders and adds a decision: Händlerbund notes that DHL's identity check of the recipient disappears, so the shop carries the fraud risk. Build it as a per-order rule (known customer, prepaid method, basket under a threshold) that decides whether the registration-free option is shown, rather than a global switch.
Where Pango sits
Pango's checkout treats a Packstation as a delivery method: the station comes from a picker, the post number is collected and validated before the order is placed, and both are carried as structured fields on the order record to the warehouse and into the DHL booking, so the convention does not have to be re-created in each system. The registration-free option is a rule written per merchant and per customer. If you are expanding to Germany and want to see how your own checkout, warehouse and carriers handle a Packstation order, start with carrier management software.
The bottom line
The DHL locker consignee needs a locker ID and a post number as separate fields. Give the shopper a picker and a validated Postnummer field, choose one place for the number in the order and keep it there through the warehouse and the shipping platform, guard the carrier choice, and prove it with one real order before launch.
