# Security, data handling, and compliance How DepartCart thinks about traveller data: hold as little as possible, keep card details with the payment provider, and put the detail in your agreement. Every partner review opens with the same three questions, dressed in whichever template the reviewer inherited. What data do you take. Where does it go. What happens if you lose it. Those are good questions, and this page answers them at the level a public page should: posture and obligations, not mechanism. DepartCart is built to hold as little partner and traveller data as it can. Card details are handled by the payment provider rather than by us, links into the cart are protected and time-bounded, and what is retained is retained because servicing the purchase requires it, not because it might be useful one day. ## Data minimisation is the only control that never fails Every other safeguard can be misconfigured. Data you never collected cannot be. That is the whole reason minimisation sits first here rather than as a closing paragraph about best practice. In practice it means we ask for what is needed to identify the booking an offer is being built for, and we stop there. Marketing lists, loyalty history, travel patterns, and full passenger profiles are all valuable to you and worthless to us. They should stay with you, and a review that finds we hold none of them has just removed most of its own workload. ## Card details stay with the payment provider The traveller pays once, and their card details go to the payment provider rather than to us. That is a deliberate boundary, not an implementation detail that happened to work out. Holding card data brings a set of obligations that we have no reason to take on, and taking them on would make us a worse vendor rather than a more capable one. For your review this collapses a whole section of the questionnaire into one line, which is the point. ## Links into the cart are protected and time-bounded A link that opens a traveller's cart is protected, and it does not stay valid indefinitely. Both of those are outcomes you can hold us to and write into an agreement. How it is done is not published here, and that is a decision rather than an oversight. Your engineers do need it, and they get it: it is set out in the [partner guide](/docs/partner-encryption-guide), which sits alongside the [integration guide](/docs/integration). **Caution:** Be wary of any vendor whose marketing page explains how its protections work. What belongs in public is the posture and the obligations. The detail belongs in a document addressed to you, with an agreement behind it. ## Who holds what | Data | Yours | Ours | The payment provider's | | --- | --- | --- | --- | | Your traveller relationships and marketing data | Yes | No | No | | The reservation of record | Yes | No | No | | Enough of a purchase record to service and reconcile the sale | No | Yes | No | | The traveller's card details | No | No | Yes | Retention follows from that table. We keep a purchase record for as long as servicing and reconciling that purchase requires, because a sale nobody can evidence is a sale your finance team will eventually have to argue about. We do not publish a retention schedule on a marketing page, because it is a term to be agreed with you rather than an announcement, and because a number here would quietly become the answer for partners it was never written for. ## How to run your own review of us 1. **Send us your questionnaire** We would rather answer yours than have you read ours. The answers differ by integration route, so a generic published version would mislead you in one direction or the other. 2. **Decide what you are actually going to send** Most partners can send materially less than they first assume. Work that out before the contract rather than after, because it is far harder to stop sending a field than to never start. 3. **Write us into your own privacy notice** You hold the relationship with the traveller and with your regulator. Our side is set out in the privacy policy at /privacy-policy, and yours needs to reflect that a post-booking cart is part of the journey. 4. **Put the specifics in the agreement** Retention, deletion, notification, and who may be involved in delivering the service are all terms. They belong in a signed document, where they can be enforced, rather than in a page that can be edited on a Tuesday. ## Your obligations do not transfer Choosing a vendor moves work. It does not move accountability. You remain the party your traveller trusted and the party your regulator will contact, and no amount of diligence on us changes that. The practical version: decide who at your end owns this before the first integration call, not after the security review has already stalled twice. Teams that name an owner early tend to finish the review in a fraction of the time, because someone is in the room who can say what is acceptable. If you have not yet chosen how you will integrate, the [integration options page](/platform/integration-options) covers the three routes, and the answers to several of these questions depend on which one you pick. ## Send us your review pack We will answer your questionnaire against the route you are considering rather than against a generic one. [Talk to us](mailto:hello@departcart.com) ## Frequently asked questions ### Will you complete our security questionnaire? Yes, and we would rather answer yours than publish a generic version here. The honest answers depend on which route you integrate through and what data you decide to send, so a page written for everyone would be wrong for you in both directions. ### Do you hold our travellers' card details? No. Card details are handled by the payment provider. We do not want them, we do not need them to do our job, and every obligation that comes with holding them is one your review does not have to spend time on with us. ### What data do you actually need from us? Enough to identify the booking an offer is being built for, and no more. Marketing lists, loyalty history, full passenger profiles, and anything else that is valuable to you and useless to us should stay where it is. ### Do you publish your security certifications? We do not claim certifications we do not hold, and we will not imply them with careful wording either. Ask us directly what we hold and what we do not, and you will get a plain answer you can put in your file. ### Where is the technical detail our engineers will ask for? In the partner guide at /docs/partner-encryption-guide, alongside the integration guide. Detail of that kind belongs in a document with your name on it and an agreement behind it, not on a page a competitor can read.