A bigger trading table.
Still a simple swap.

International Pokémon card trading for adult collectors and parent-managed families. The defining experience: build a bundle, negotiate clearly, agree on exact terms, and follow both sides of the exchange.

New in the 10 October build

The original trading glen adds a lantern-lit pixel woodland, warm game-style panels and a collector journal. The separately packaged shared beta now has a private wish book, exact-version matches against friends’ available shared cards, a spare-copy filter and binder totals. These changes are tested locally and have not been deployed. The wish book is account-backed in that beta; this standalone demo retains its sample-card wish list.

Wishes are private. Two-way wish sharing and automatic reciprocal bundle suggestions remain future features. A spare is an unreserved copy beyond the one kept in the same entry; entries are not merged. Matches do not authenticate cards. No billing, external pricing feed or private photo upload has been activated.

Membership and a sustainable trading service

The Pro Trainer preview compares proposed monthly and annual prices and per-collector exchange fees. Its calculator shows when Free costs less. Current demo trades remain fee-free; Pro benefits and billing are not connected. The revenue and simplicity brief explains competitor inspiration, unit economics, the pricing pilot and launch decisions.

Binder and trade views now put their lists first. Card details lead directly to an offer or inspection-photo preparation. Saved drafts lead with Continue draft, and dispatch/receipt stages have one primary action. Parent review, safety review and changed-term consent still apply.

The strongest improvements to the original idea

Other ideas worth testing, in order

1. Multi-card swaps on both sides. Add two-for-three and whole-binder bundles after one-for-many feels effortless. Keep one clearly agreed offer version.
2. A reputation you can understand. Completed trade counts and separately explained packing, accuracy and communication feedback. Never imply that a badge guarantees authenticity.
3. Language-aware discovery. Search the same Pokémon across English and Japanese printings, but keep variants and editions visibly distinct. Match rules to what each collector actually wants.
4. High-value verification. Explore an optional expert checkpoint or trusted intermediary for rare cards. Treat this as a staffed service with clear costs and responsibilities, not an automatic “authentic” label.
5. Club trade tables. Private collector clubs or event groups with parent-managed membership. Test demand before adding public chat or meetups.

What makes the prototype easier to use

• Card condition and value stay visible while building a bundle.
• Cash is optional and uses exact pounds and pence, with a separate postage budget. Invalid amounts and the demo £250 cap are checked before review; the total clearly asks for correction instead of silently treating invalid cash as zero.
• Review comes before a proposal; a changed counteroffer is highlighted and needs agreement.
• Family proposals and changed offers pass through parent review in the simulation.
• Cards are reserved at agreement; conflicting offers are closed and unshipped cancellations release reservations.
• Delivery tracks both collectors’ dispatch and receipt; a problem pauses the trade instead of pretending it is complete. Later problems can be recorded after completion while keeping traded cards unavailable. A read-only trade-record view shows the saved card conditions, cash, route and history for any status. The underlying browser data remains editable and is not verified evidence.
• Saved drafts and unfinished bundles can be resumed. Older demo offers become drafts for fresh review. Changes from another tab refresh open confirmations and clear old consent; an old editor restores the latest terms before saving. Counteroffer editing begins with the current counter amount.
• Secondary trade actions sit under “More options” to keep the main next step obvious. Review gates lead with parent approval, safety review, then agreement; pending safety reviews appear under “Needs attention.”

Security, scam prevention and financial-crime controls

No service can promise zero scams or money laundering. The live goal is to reduce opportunities for abuse, detect suspicious activity and provide a staffed response. The current browser prototype is editable local data; it provides no real identity, authorization or financial-crime screening.

• Implemented demo rules: £250 cash top-up cap; proposals reject obvious outside-payment links, contact details and payment redirection; unusually cash-heavy and repeated proposals require an explicit simulated safety review. A changed version clears that review. These are illustrative product rules, not statutory thresholds or an AML system.
• Server authority: authenticated users, deny-by-default ownership and role checks on every operation, version-bound approval, transaction-safe inventory locks, request rate limits and idempotent processing. Client flags, local history and mode switches must never authorize real trades or payments.
• Payment design: use a suitable regulated provider for supported countries and currencies. Do not introduce transferable wallet balances, peer-to-peer withdrawals or off-platform payment instructions. Refund to the original funding source using provider-approved procedures. Never claim that a payment provider automatically protects the exchanged cards.
• Risk review: design identity and beneficial-owner checks, sanctions/PEP screening where required, ongoing activity review, value plausibility, repeated/circular trades and linked-account investigation with qualified advisers and the provider. Card value and low cash amounts alone cannot prove a trade is legitimate. Applicable legal duties depend on the business model and jurisdictions.
• Account and family security: strong authentication and recovery, reauthentication for sensitive changes, verified parent relationships, and parent control of cash and communication. Do not allow a child to bypass parent approval by choosing a different client-side mode.
• Evidence and privacy: protect card and ownership photos, keep submitted evidence linked to the exact agreed version, restrict access to trading parties and authorized reviewers, remove location metadata, scan/re-encode uploads, reject active file formats and minimize retained personal data.
• Operations: staffed reporting/blocking, a dispute process, review access controls, protected audit logs, clear retention rules and independent security testing before enabling live transactions. Holds and rejected trades need an appropriate review/appeal process.

Engineering reference: OWASP transaction authorization. Financial-crime planning reference, whose applicability needs professional assessment: FCA financial crime guide.

Inspection photo flow

My binder now includes a local photo-preparation studio: full front, full back, top corners, bottom corners, angled-light surface, side edges and a card-with-code ownership view, plus extra damage close-ups. Selected files can be opened at full size. Each slot shows its minimum resolution before selection. Phone-transfer guidance covers full-resolution files, keeping originals and exporting supported copies of HEIC/HEIF photos; the prototype performs no conversion or device-to-device transfer. Genuine JPG/PNG/WebP signatures, a 20 MB file limit, a 24-megapixel decoded-image limit and view-specific resolution minima are checked. Pixel limits are checked after browser decoding, so they are not a secure upload-processing boundary. Mixed batches with an invalid photo preserve the existing set and release newly created previews. File reads and image opening each have a 15-second UI timeout; closing, switching, replacing or clearing cancels unfinished selections. Temporary previews, handlers and timers are cleaned up. These controls cannot guarantee that a browser stops decoding or respects a hard memory/time budget. Sharpness, glare, framing and completeness still require manual inspection; resolution alone cannot establish condition or authenticity.

Photo preparation stays in this tab; files are not uploaded, saved or attached to a live offer. The ownership code is a demo prompt. A real service needs a server-issued expiring challenge, private uploads, metadata removal, evidence versioning, secure access and a reviewer process. Preserve originals securely for disputes while supplying safe inspection copies. Parents should manage photography and uploads for younger collectors.

Collector disputes and platform responsibility

The draft responsibility notice separates each collector’s exchange obligations from Tradle’s own service duties. The proposed route for unresolved collector disputes is an eligible independent service, with access to courts and legal rights preserved. No provider is appointed, no live referral exists, and the prototype does not decide liability or compensation.

Before launch, obtain country-specific legal review, select a provider that accepts the intended private/business, barter/cash and international disputes, disclose eligibility, fees and deadlines, and implement protected referrals and records. Continue to operate platform complaints, moderation, fraud reporting and family safeguarding. A disclaimer does not replace these functions.

Before anyone can trade for real

Closed counteroffers keep their latest cash amount in the trade list, record and renewal form. Declining, withdrawing or expiry never changes those terms back to the original amount. Earlier versions remain available separately.

The proposal review is tied to the exact cards, cash, condition snapshots and delivery budget shown. If another tab changes the delivery country, the review refreshes and requires a new check before proposing. Unfinished family bundles keep family rules when resumed under the adult demo profile. These local protections do not verify a real parent or replace server authorization.

Verification and remaining review

Desktop screenshot review: the user-supplied home-screen image confirms the warm theme and four-column desktop layout render at that viewport. It exposed condition labels hidden by card artwork. The updated CSS places labels and wish buttons in a separate row above the images, including image-failure text. The revised layout still needs a refreshed screenshot; keyboard, touch, small-screen and photo-dialog behaviour remain unverified in a real browser.

Twenty-six trading-rule checks and scripted application scenarios cover offers, changed parent approval, money, reservations, delivery, disputes, international routes, immutable card details, wish lists, draft restore and storage recovery. These are behaviour checks, not browser screenshots or a live trading trial.

Source review improved narrow-screen reflow, larger text, focus visibility and keyboard focus after wish-list changes. Actual visual, touch and keyboard testing in a permitted browser remains outstanding. The separate invitation-only beta was deployed on 6 October. This 10 October visual/discovery update is local and awaits publication; its new layout is not browser-verified.

Proposed inspection evidence lifecycle

1. Prepare and explain. Guide each required view, show original-size inspection and disclose who can see the images. Keep addresses, faces and unrelated documents out of card photos.
2. Receive privately. An authenticated backend checks listing ownership and issues short-lived upload permission. Quarantine incoming files; enforce byte limits and aggregate upload quotas, inspect dimensions before expensive decode, use isolated processing with hard memory/CPU/time budgets, decode and re-encode supported formats, remove location metadata and create inspection previews before allowing access.
3. Link an exact version. Record the server-issued ownership challenge, image identifiers and listing version. Collectors review that exact condition evidence before agreement. Replacing evidence invalidates relevant approvals and requires fresh review; catalogue artwork is never condition evidence.
4. Restrict and review. Authorize each evidence request for the collector, their verified guardian where applicable, or assigned reviewer. Use expiring access, access records and a staffed reporting process. A photograph can support inspection but cannot guarantee authenticity or ownership.
5. Resolve and retire. Preserve the agreed evidence version during a dispute under a documented retention policy. Define deletion, appeal and any justified hold before launch; remove expired access and stored derivatives consistently. Do not invent a retention period without operational and jurisdiction-specific review.

This is a proposed backend design. The current tab-only photo studio does not implement uploads, metadata removal, secure evidence storage or offer-linked evidence.

A practical rollout

1. Validate the experience. Ask collectors and parents to build a trade without instruction. Watch for mistakes with condition, cash direction, counteroffers and cross-border costs.
2. Connect a private beta. Add real account permissions, shared inventory, immutable offers, photo evidence and transaction-safe reservations. Keep payments disabled until provider and operational decisions are complete.
3. Launch a few supported international routes. International intent does not mean every country is supported immediately. Publish the exact routes, currencies and delivery terms that work.
4. Expand by evidence. Add languages, more routes, two-way wish-list matching and multi-card swaps as demand and support capacity grow.

Chosen name and visual direction

Tradle is the user-selected prototype title, pronounced “TRAY-dul.” The new interface takes its warmth from warm parchment binder pages, soft card pockets, forest-green controls and burgundy panels and an original two-card exchange emblem. Small foil glints and geometric details evoke collecting without reproducing franchise interface assets.

The name is already used by other products, including an existing Tradle software organisation. This is an initial conflict finding, not trademark clearance. Review the name, domains and catalogue artwork permissions before a public launch. The custom interface artwork does not grant rights to Pokémon card images.

Source notes for launch planning

The ICO’s Children’s Code sets out age-appropriate privacy standards, including a risk-based approach to age and geolocation off by default. Use these as design inputs and obtain jurisdiction-specific review before launch. ICO standards.

Goods arriving in the UK from abroad may attract VAT, duty or other charges. Do not label a negotiated card swap as a gift to imply tax-free treatment; obtain correct route-specific guidance. GOV.UK import overview · Gift rules.

Earlier offer versions now preserve cash, offered and received condition snapshots, delivery and family mode when terms are revised or countered. Up to 100 earlier versions are retained; legacy missing history cannot be reconstructed. This is locally editable demo history, not protected evidence.