Merchant Terms and Data Processing Agreement
Orbital Technologies LLC — warehousesystem.app
Version 2.0 · 10 November 2026
Published at: https://warehousesystem.app/legal/merchant-terms
Supersedes the separate Shopify Integration Terms and Data Processing Agreement, both version 1.0 of 24 October 2026, which this document replaces.
How this document works
This agreement is between Orbital Technologies LLC ("Orbital", "we", "us") and the business using warehousesystem.app ("the Customer"). The Customer may be a warehouse operator, or a merchant using a warehouse operator's service.
It has two parts.
Part One sets out how the service works when a merchant connects a Shopify store: what we read, what we write back, when we accept and reject, what happens to stock, how an order is stopped, how returns are handled, and what each side is responsible for.
Part Two covers one thing: what Orbital is allowed to do with personal information that belongs to the Customer and to the Customer's own customers. The Customer decides what happens to that information. Orbital only acts on the Customer's instructions. In data protection language, the Customer is the controller and Orbital is the processor.
This agreement sits alongside our main service agreement. If anything here conflicts with it, this document wins on anything to do with the Shopify connection or with personal information. Everything else is governed by the main service agreement, including the limits on liability.
It takes effect when the Customer starts using the service, or connects a store, and stays in force for as long as Orbital holds any of the Customer's data.
What personal information we handle across the whole platform, and the rights people have, is set out separately in our Privacy Notice.
Part One — Service and integration terms
1. What connecting a store does
Once a store is connected, the warehouse appears in that Shopify store as a fulfilment service, under the warehouse's own name, with a location.
When the merchant requests fulfilment on an order, Shopify tells us. We read that order from the store, check it, and either accept it or reject it with a reason the merchant reads on the order in Shopify.
When the merchant approves a return in Shopify, Shopify tells us, we read the return back from the store, and the merchant tells us what they want done with each item.
Nothing happens automatically to orders the merchant has not requested fulfilment for.
Connecting a store means accepting this agreement.
2. What we read
Only what we need to ship a parcel and process a return.
| What | Why |
|---|---|
| Order number and reference | So we and the merchant are talking about the same order |
| Line items, SKUs and quantities requested | To pick the right goods and check stock |
| Shipping recipient name | Printed on the carrier label |
| Shipping address | Required by the carrier to deliver |
| Phone number | Required by most carriers, and for delivery problems and customs |
| Fulfilment request status | To know whether the merchant has withdrawn the request |
| Return quantities and the structured return reason | To know a return is coming and why |
| Tracking on the inbound return parcel | To know when to expect it |
We do not read the shopper's email address. We removed it in October 2026 because a parcel can be shipped without it.
We do not read a billing address.
We do not read payment information. Not card numbers, not bank details, not any part of them. Shopify does not give it to us and we do not ask for it.
We do not read orders the merchant has not asked us to fulfil.
We do not keep the shopper's own written words. Where a shopper types a note on an order, or a comment explaining why they are returning something, we deliberately do not store it. The structured reason the store provides is what a warehouse needs to act.
How we read it
When Shopify tells us something has happened, we do not act on the content of that message. We take the identifier out of it, go back to that store with that store's own access, and work from what the store returns.
This matters for security. A message that did not really come from the store cannot make us do anything, because we always check with the store itself before acting.
What the store cannot tell us about a return
Shopify tells us how many units are coming back and why, but not which specific line of a multi-line order they are. We identify the goods from the order we packed, and the warehouse confirms what is actually in the parcel when it opens it. What is physically in a box is a fact about the box.
3. What we write back
| What | When |
|---|---|
| Acceptance, with our order reference and an estimated ship date | When we accept a fulfilment request |
| Rejection, with the reason and the lines that were wrong | When we cannot accept it |
| Tracking number and carrier | When the parcel ships |
| The outcome of each returned item | When the warehouse has opened the parcel and recorded what it found |
4. When we accept, and when we reject
We check every request before accepting it. If a check fails, we reject it and the merchant sees the reason on the order in Shopify.
| Check | What the merchant sees |
|---|---|
| The fulfilment orders feature is not enabled on the account | Other |
| Too many lines on the order | Order too large |
| A line is for something that cannot be shipped | Ineligible product |
| The address is missing a name, street, city or country | Incorrect address |
| A SKU in the store does not match a SKU in the catalogue | Invalid SKU, naming each line |
| Not enough stock under the account's stock policy | Inventory out of stock, naming each line, with what was requested against what is available |
A rejection is recorded per request, not per order. A merchant can fix the problem and request fulfilment again on the same order.
SKU matching
A SKU in the Shopify store must exactly match a SKU in the merchant's catalogue in warehousesystem.app. Capital letters are ignored, and so are spaces at the start and end. Nothing else is. We do not guess at near matches.
This is deliberate. A near match that guesses wrong puts the wrong goods in a box and sends them to a real person. A rejection is something the merchant reads and fixes in a minute.
The merchant is responsible for keeping SKUs the same in both systems.
Short orders
If the account is set to ship whatever is available, we accept the part we can ship. If the account is set to hold until an order is complete, we reject the request rather than leave the order waiting with no visible status in Shopify.
5. Stock
When we accept a request, we hold the stock for that order. Held stock is not available for anything else.
If the merchant withdraws the request before we accept it, no stock is held. Cancelling after we have accepted is covered in section 6.
6. Stopping an order after we have accepted it
A merchant can stop an accepted order in four ways, and all four reach us:
- a cancellation request raised in Shopify;
- a cancellation forced through in Shopify;
- the Stop button in warehousesystem.app;
- a cancellation entered by warehouse staff on the merchant's instruction.
A merchant can also place an order on hold in Shopify and release it again, and the warehouse floor stops and restarts with it.
Where cancelling stops being possible. An order can be stopped at any point until a carrier label has been bought for it. Once a live label exists, the parcel is committed to the carrier and the order can no longer be cancelled. This applies to the order as a whole. If a label has been cancelled, it does not count.
7. Returns
When the merchant approves a return in Shopify, it appears in warehousesystem.app and the merchant tells us what they want done with each item: put it back into stock, check it over first, or dispose of it.
The merchant can give that instruction before the parcel arrives, which is the point. The warehouse should know what to do when it opens the box rather than stopping to ask.
When the parcel arrives, the warehouse books it in, opens it, and records what it actually found: put back into stock, set aside to be checked, disposed of, or not in the parcel at all.
The instruction and the outcome are kept as two separate records, and they are allowed to disagree. A merchant may ask for an item to go back into stock and the warehouse may open the box and find it broken. Both screens show both, and say plainly when they differ. We do not overwrite what a merchant asked for with what we found, or the other way round.
Only goods recorded as fit to sell are returned to sellable stock.
8. Current limitations
This section is kept accurate deliberately. It is the part merchants will hold us to.
| Limitation | Status |
|---|---|
| We do not yet publish our stock levels to the Shopify location. The location shows zero, so a merchant can only take orders by enabling "continue selling when out of stock" in Shopify | Being built. This is the largest gap in the integration today |
| There is no screen for mapping a store SKU to a different catalogue SKU. SKUs must match exactly | Planned before a second merchant is signed |
| A return has to be approved by the merchant in Shopify. We cannot raise a return on the merchant's behalf from inside warehousesystem.app | Being built |
| Returned goods marked as needing inspection, or as not fit to sell, are held and reported to the merchant, but are not yet placed into a tracked storage location | Being built |
| A rejected short order uses up an order reference number, so our references can skip | Cosmetic. No effect on the order |
| There is no list of rejected requests inside warehousesystem.app. Rejections are shown in Shopify, on the order | By design. One place to look, not two |
9. What the merchant is responsible for
- Keeping SKUs the same in the store and in the catalogue.
- Keeping product weights and dimensions accurate. These decide the carrier rate, and a wrong weight means a wrong price.
- Having the right to send us the shopper details on their orders, and having told their own shoppers what happens to them.
- Checking rejected requests and acting on them. A rejected request sits unfulfilled until the merchant does something.
- Approving returns in Shopify, and telling us what to do with the goods.
- Not sending us special category data, payment data, or anything else we do not need to ship a parcel.
10. What we are responsible for
- Acting only on fulfilment requests the merchant submits.
- Giving a clear reason, on the order in Shopify, every time we reject one.
- Never silently ignoring a request. If something fails on our side it is recorded, retried, and raised as an exception for our staff to deal with. A scheduled job checks for anything we have not answered, independently of whether Shopify tells us again.
- Protecting personal information as set out in Part Two and in our Privacy Notice.
- Erasing data within the timeframes in section 11 and section 19.
11. Uninstalling, and erasing data
If the merchant uninstalls the app, Shopify tells us and we stop using the store's access immediately. When Shopify then sends its shop erasure request, which arrives about 48 hours after the uninstall, we delete the store connection, its access token, its sync history and its mappings, erase the shopper details on every order from that store, and cancel any order not yet shipped. The merchant's own account, stock and order history in warehousesystem.app are not affected.
If a shopper asks the merchant to erase their data, Shopify tells us and we erase that shopper's details from the orders we received from that store, on receipt of the request.
An order erased at a shopper's request cannot be revived. If the store sends it to us again, we refuse it and tell the merchant why.
Reinstalling gives a fresh connection, and the store starts afresh.
The retention periods behind all of this are in section 19.
12. Suspension and disconnection
The merchant can disconnect at any time by uninstalling the app in Shopify.
We may suspend the connection if a merchant's account is suspended, if the connection is being used in a way that breaks this agreement, or if we are required to by Shopify. Where we can, we tell the merchant first. Where we cannot, we tell them as soon as possible afterwards.
13. Shopify is not a party to this
Shopify provides the platform. This agreement is between the Customer and Orbital Technologies LLC. Shopify is not responsible for our service, and we are not responsible for Shopify's.
Part Two — Data processing
14. What we process, and why
| Item | Detail |
|---|---|
| Subject matter | Warehouse, fulfilment and package forwarding services provided through warehousesystem.app |
| Duration | For as long as the Customer's account is active, plus the retention periods in section 19 |
| Nature and purpose | Receiving goods, holding stock, picking and packing orders, buying carrier labels, shipping parcels, receiving and processing returns, forwarding parcels where that module is enabled, and reporting back to the Customer and their sales channels |
| Categories of people | The Customer's own customers and the recipients of their parcels; where the package forwarding module is enabled, the Customer's forwarding account holders; the Customer's own staff who hold logins |
| Categories of data, fulfilment and returns | As listed in section 2: name; shipping address; phone number; order number and reference; items, SKUs and quantities; parcel weight and dimensions; tracking number; return quantities and the structured return reason |
| Categories of data, package forwarding | Name; mailbox or suite number; warehouse delivery address and the person's own destination address; phone number; email address; photographs of the parcel; a record of its contents; declared value |
| Categories of data, Customer staff | Name, work email, phone, role and activity record |
| Data Orbital does not receive | Billing address; payment card or bank details; the shopper's own free-text notes or return comments; a shopper's email address from a connected sales channel |
| Special category data | None. Orbital does not request it and the Customer must not send it |
15. Orbital's obligations
Orbital will:
- Process only on instruction. Orbital processes personal information only to provide the service, and only as the Customer instructs. Using the system, connecting a sales channel and submitting orders are all instructions. If Orbital is ever required by law to process something beyond that, Orbital will tell the Customer first unless the law forbids it.
- Not sell or share it. Orbital does not sell personal information, does not share it for advertising, and does not use it for its own purposes.
- Keep it confidential. Everyone at Orbital with access is bound by confidentiality obligations and is told what they may and may not do with it.
- Keep it secure. Orbital applies the measures set out in Annex A, and will not reduce them during the term.
- Help the Customer answer requests. If a person asks the Customer for a copy of their information, for correction, or for deletion, Orbital will provide what the Customer needs, or act on the Customer's instruction directly, without undue delay and at no charge. If a request comes to Orbital first, Orbital will pass it to the Customer rather than answer it.
- Report security incidents. Orbital will notify the Customer without undue delay, and in any event within 48 hours, of becoming aware of a personal data breach affecting the Customer's data. The notification will say what happened, what data and roughly how many people are affected, what Orbital is doing about it, and who at Orbital to contact. Orbital's full procedure is its Security Incident Response Policy, available on request.
- Help with assessments. Orbital will give the Customer the information it reasonably needs for a data protection impact assessment or a consultation with a regulator.
- Allow audit. Once in any twelve month period, on 30 days' written notice, the Customer may ask Orbital to demonstrate compliance with this agreement. Orbital will answer a written security questionnaire and provide its current security documentation. If that is not enough for a specific, documented concern, the parties will agree an on-site or remote audit, at the Customer's cost, that does not disrupt the service or expose another customer's data.
- Delete or return at the end. On termination, Orbital will delete the Customer's personal data within 30 days, or return it first if the Customer asks within that period. Orbital may keep a copy only where the law requires it, and the terms of this agreement keep applying to that copy.
16. The Customer's obligations
In addition to section 9, the Customer will:
- Make sure it is allowed to give Orbital the personal information it sends, and that it has told its own customers what will happen to it.
- Not send Orbital special category data, payment data, or any information Orbital does not need to provide the service.
- Where the package forwarding module is enabled, decide what is collected from its forwarding account holders and how long it is kept, and instruct Orbital accordingly.
- Keep its own account details accurate, and remove staff logins promptly when people leave.
- Give instructions that are lawful.
17. Sub-processors
The Customer agrees that Orbital may use the sub-processors below.
| Sub-processor | What they do | What they receive | Where |
|---|---|---|---|
| InterServer | Hosts the server the system runs on | Nothing directly | United States |
| Easyship | Obtains carrier rates and buys labels | Shipment details: name, delivery address, phone, weight and size | Varies by warehouse |
| Carriers selected by the Customer, for example USPS, UPS, FedEx, DHL | Deliver the parcel | The same shipment details | Varies by shipment |
| Shopify | The Customer's own sales channel, where orders and returns come from and status goes back | Order and return status, acceptance or rejection, tracking numbers, return outcomes | United States |
| Mailtrap | Delivers Orbital's notification emails | The recipient's email address and the content of the message | As stated in Mailtrap's own terms |
| Anthropic | Powers the in-platform assistant, where the Customer has enabled it | A snapshot of the records the signed-in user is already permitted to see, which may include mailbox, package and shipment details | United States |
Used only where the Customer switches them on, and not in use by default: Google Cloud Vision and Google Gemini, for reading a carrier label at intake; WhatsApp, for notifications.
Orbital stays responsible for its sub-processors. Each one is bound by terms no weaker than this agreement.
If Orbital wants to add or replace a sub-processor, it will tell the Customer at least 30 days in advance. If the Customer reasonably objects within those 30 days, the parties will try to find a solution. If they cannot, the Customer may terminate the affected part of the service without penalty.
18. International transfers
Orbital's servers are in the United States. Orbital's staff access the system from Pakistan.
Where the Customer or its customers are in the United Kingdom or the European Economic Area, the parties adopt the European Commission's Standard Contractual Clauses (Module Two, controller to processor) and, for the United Kingdom, the UK International Data Transfer Addendum. Those clauses are incorporated into this agreement. Annex A serves as the technical and organisational measures annex required by those clauses.
This agreement is governed by the laws of the State of Florida, United States. The Standard Contractual Clauses are governed by their own terms, and nothing in this section displaces a right a person has under the law where they live.
19. Retention
Fulfilment orders and returns
| What | How long |
|---|---|
| Customer's own customer name, address and phone attached to an order | Erased 90 days after the order ships, or 90 days after it is cancelled, by an automatic daily job that reports every run |
| Order and return records with those fields removed | Kept as a business record for the life of the account |
| All data from a sales channel after the Customer disconnects it | Erased when the channel sends its erasure request, which arrives about 48 hours after the uninstall. Any order not yet shipped is cancelled at that point |
| Individual data on an erasure request | Erased on receipt |
Package forwarding
| What | How long |
|---|---|
| Forwarding account holder records, parcels, photographs and contents | Kept for the life of the Customer's account. The Customer sets any shorter period and may instruct Orbital to delete records at any time. Orbital applies no automatic limit of its own to this data today |
Both
| What | How long |
|---|---|
| The Customer's own account and staff records | For the life of the account, then deleted under section 15.9 |
| The log of who viewed a shopper's details | 12 months |
20. Changes
If we change this agreement we will update the date and version at the top and tell connected Customers before the change takes effect.
Annex A — Security measures
These are the measures Orbital applies. They are a contractual commitment, not a description.
Separation by warehouse operator. Each warehouse operator on the platform is provisioned with its own isolated database. Data belonging to one operator is never stored alongside another's, and there is no shared table of customer records.
Separation by business within an operator. Each merchant's data, meaning their connected stores, orders, returns and inventory, is restricted by access controls enforced on Orbital's servers for every request. A merchant can only retrieve records belonging to the business they are signed in to.
Encryption at rest, fulfilment and returns data. The shopper's name, address and phone number on a fulfilment order or return are stored encrypted with AES-256-GCM, using a dedicated key held separately from the database. The shipping label image and the address copy on a shipment are encrypted the same way. A stolen database file or backup does not reveal those fields.
Encryption in transit. All traffic to and from the system, to sales channels and to carriers uses HTTPS. Plain HTTP is redirected.
Encrypted backups. Database backups are AES-256 encrypted, and a restore has been performed and recorded.
Credential handling. Sales channel access tokens and webhook signing secrets are stored encrypted and are never returned to any browser or client.
Minimum data. Orbital stores only the order and return information needed to provide the service. Shoppers' free-text notes and return comments are not stored, and a guard in the test suite prevents them being added.
Access control. Access is granted by role, on a least privilege basis. Warehouse staff see only what their job requires. Administrative access is held by named individuals.
Access logging. Every view of a shopper's name, address or phone on a fulfilment order, and every label print, is recorded with the user, the screen and the time, before the data is returned. The log is retained for 12 months.
Automatic deletion. Retention on fulfilment and returns data is enforced by a job that runs daily and reports every run, not by anyone remembering to do it.
Change control. Every change is reviewed by a second person and must pass the automated test suite and a full build before release. An urgent fix to a live fault may be released first and reviewed immediately afterwards, and the pull request records that it happened that way.
Incident response. Orbital maintains a written Security Incident Response Policy with defined severities, owners and notification timelines.
Data loss prevention. Orbital maintains a written Data Loss Prevention Strategy covering where data lives, how it is protected, and how it leaves the system.
Scope of these measures
Field level encryption at rest, the automatic 90 day deletion and the access logging described above apply to fulfilment and returns data. They are not applied to package forwarding records today. Forwarding records are protected by the operator's own isolated database, by HTTPS in transit, by encrypted backups, and by role based access control. Extending the remaining measures to forwarding data is planned work, and Orbital will not describe it as done before it is.
Questions: support@orbitaltechltd.com
Signature block
Where a Customer requires a countersigned copy, this page is used. Otherwise acceptance is as set out under "How this document works".
| Orbital Technologies LLC | The Customer | |
|---|---|---|
| Name | ||
| Title | ||
| Date |