Photo · Pexels

Security

How we protect each step — buying, sending, opening, collecting, and spending — for gift cards, Treats, and your account.

For password and email verification, see Account security. For legal wording, see Privacy.

Sign-in and your account

Your account is how you buy gifts, see what you sent, and manage affiliate settings.

Sign-in. We use Amazon Cognito for passwords and social sign-in. Session tokens live in httpOnly cookies, not in page JavaScript.
Access to your presents. Only the signed-in buyer (or the guest session that created a gift) can change or pay for that purchase.
Password and email. Change your password and confirm your email from account security in your dashboard.

From choosing a shop to paying, we keep checkout on trusted payment rails.

Configure before pay. Delivery, message, and amount are saved on your present. Sensitive payment fields are never shown back to browsers or MCP clients after funding.
Pay with GoCardless. Open banking and card checkout run on GoCardless hosted pages. We do not store your bank login or card PAN on our servers.
Payment confirmed before issue. A gift card is not bought from the issuer until we have a confirmed payment. That work runs on a separate worker, not in the public web container.
Webhooks. GoCardless payment notifications hit a Cloudflare Worker at the edge, are signature-checked, and are queued for processing — they are not handled as ordinary web pages.

Email, text, or a link you copy yourself — each path keeps the gift tied to the code you chose.

Scheduled delivery. Send-now and send-later jobs are queued with delays or one-shot schedules so the link goes out at the time you picked.
Email and SMS. Messages include the gift link (and your written note in email). We send through our mail and SMS providers; we do not sell recipient addresses.
Short links (pstpst.link). Texts and some emails use our short domain. It redirects to postandpresent.co.uk so you can recognise official links. Only open links you were expecting.
Manual share. If you copy the link yourself, you control the channel. The same gift code and the same collection rules apply.

The recipient sees the shop and amount first; personal content unlocks after they prove they received the link.

Gift code in the URL. Each gift has a high-entropy code. Guessing codes is slowed by rate limits at the edge and in the app.
Email confirmation. Your note, voice, video, and the spendable gift card details appear after the recipient confirms the email address the gift was sent to (or signs in as that person).
Brand choice. Where we offer it, they can pick the brand card or a prepaid alternative at the same value — still only after that confirmation step.

Collection turns the gift into a shop card; redemption stays locked to one email.

Collect page. Recipients can type a code from a printed card at /collect. The same email checks apply before value is released.
One redemption. After collection, the claim is tied to that redeemer email. The spendable reward URL is not exposed in preview APIs before claim completes.
Spend at the shop. The issued card follows the retailer’s own terms. We do not see in-store basket details.

Small in-person Treats use an open link, but the prepaid card waits for a recipient email.

Longer link token. Treat URLs use a longer random token than gift codes because anyone with the link can open the page.
Email before issue. The recipient enters an email on the Treat page. We issue the prepaid card and email a secure open link — not before that step.
One claim. After the email is saved, the public Treat page shows that it was already claimed. The emailed link sets a scoped cookie so only that browser session can reopen the card.

Personal media is private storage, not public uploads.

Upload. Recordings and uploads go to private object storage with type and size checks.
Playback. Recipients and buyers stream through time-limited signed URLs, not permanent public links.
Response messages. When someone sends a thank-you clip back, it is stored under that gift and notified to the buyer — not posted publicly.

Partners trigger gifts from their checkout or AI tools with org-scoped credentials.

Organisation credentials. Each affiliate has its own MCP client id and secret (or mock credentials in dev). Tools act only for that organisation.
Line-item settlement. Checkout can reserve prepaid balance on the org account so concurrent orders cannot double-spend the float.
Agent payments. Some MCP checkouts charge via Stripe shared payment tokens on our server; issuance still moves to the worker queue after payment succeeds.

We store what we need to deliver and support gifts — nothing sold to brokers.

Contact details. Names, emails, and phone numbers for delivery are encrypted at rest with keys managed in AWS.
Retention. We keep purchase and claim records for support, fraud prevention, and legal requirements described in our privacy policy.
No sale of personal data. We do not sell your data or your recipients’ data. Questions: hello@postandpresent.co.uk.