> ## Documentation Index
> Fetch the complete documentation index at: https://docs.regasolutions.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Your Vestiaire accounts
> Where a Vestiaire account is connected, what rega keeps of it, the five points that decide whether it can buy, and the two traps we have measured: a connection can be whole for browsing and refused for buying, and the basket belongs to the whole account.
The radar finds listings for everybody at once; **an account is what turns a find into a gesture** — a heart, an offer, a purchase. Until you have connected one, the marketplace is watched and nothing more, and the Accounts screen says so on its door: “No account on this marketplace — nothing will buy there”. A Vestiaire connection lasts **30 days exactly**, and the marketplace offers nothing to refresh it along the way. That single fact governs most of this page.
***
## Where your Vestiaire accounts live
There is no Vestiaire screen. The menu carries eight entries — dashboard, filters, accounts, orders, watchlist, sales, statistics, settings — and none of them is named after a marketplace. Vestiaire is spread through the product instead: its listings arrive in the same feed as your Vinted ones, its filters sit in the same list, and its accounts live behind a door on the **Accounts** screen.
That screen opens on two doors, one per marketplace. **It is the only screen in the whole product where the two marketplaces are kept apart.** The reason is written into the product: a group of accounts exists to take turns buying, and taking turns between Vinted and Vestiaire means nothing — they share neither their listings, nor their basket, nor their payment.
| What you read on the door | What it tells you |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| “Vestiaire Collective” | The name is always written out, next to its colour — never a colour on its own |
| “`{n}` account(s) · `{n}` group(s)” | Counted from your real accounts. Until the figures arrive, the door writes **nothing** rather than a “0” it has not checked |
| “reading…” | The counters are on their way |
| “counters unavailable” | They could not be read. The door still opens |
| “TO CONNECT” | You have no account on this marketplace. Its tooltip: “No account on this marketplace — nothing will buy there” |
| “Accounts cannot be reached at the moment.” | Neither door can be counted right now |
| “Open the Vestiaire Collective accounts” | The name of the door itself, for a screen reader |
| “← All marketplaces” | Back to the two doors. It is the only way out of a door |
| “Vestiaire accounts” | The heading of the list, once you are through |
**The open door is not in the address.** Which marketplace you have opened lives on the screen, not in the link — so a Vestiaire account page cannot be bookmarked, and there is no shortcut that lands straight on it. The way in is always the same: **Accounts**, then the Vestiaire door.
On a phone, **Accounts** sits under “More” in the bottom bar, and the screen shows one column at a time — the list, or the account page, with an arrow back.
Nothing is read from the marketplace when the application starts. A door is only counted when you look at it, and an account is only questioned when you open it.
### Groups, on the Vestiaire side
Groups work here as they do on Vinted, with two differences the window states itself. The subtitle is the same — “A group gathers accounts in an ORDER. Deleting a group deletes no account.” — followed, on this side only, by “ It only holds Vestiaire accounts.”
* A group offers you **Vestiaire accounts only**. A mixed group is refused by our servers, not merely discouraged.
* There is **no role** on a Vestiaire account. The buying/enriching distinction does not exist on this marketplace, so every account is eligible for every group.
* There is **no “switch account after `{n}` purchases”**. That setting is Vinted's.
* A group with no connected account says so: “No account connected — this group will buy nothing”, and an empty one: “No account in this group — it will buy nothing.”
* Deleting a group answers “Group deleted — `{name}` · the accounts are kept”.
***
## Connecting an account
From the Vestiaire door, the button is **“+ ACCOUNT”**, at the foot of the list. On a workspace with no Vestiaire account at all, the right-hand side shows a starting frame instead — “Connect a Vestiaire Collective account” and an “Add an account” button.
**What that account is for**, since the frame does not say it: this is the account that will buy, with its own card and its own delivery address, and the one every offer and every heart will go out from. It is not your Vinted account, and its address is not necessarily the same one.
The window is titled “Add a Vestiaire account” and it has **three fields**.
| What you see | What it is for |
| ---------------------------------------------------------------------- | --------------------------------------------------------------------- |
| “ACCOUNT NAME (optional)” — example “Main buying, Backup…” | The name you will read everywhere afterwards |
| “E-MAIL ADDRESS” — example “[you@example.com](mailto:you@example.com)” | The address of the **Vestiaire** account |
| “PASSWORD”, with a “SHOW” / “HIDE” toggle | Required. It is also what lets the account reconnect later on its own |
| “ADD AND CONNECT” | One button. While it runs it reads “CONNECTING…” |
**The password is required, and there is nothing else to paste.** Leaving a field empty is refused before anything goes out: “Address required.” or “Password required.” There is no “sign-in code” field, and no code by SMS either — that step belongs to Vinted, where connecting an account waits for a text message. On Vestiaire, it is one window and one button.
**Adding and connecting are one gesture, not two.** Our servers try the connection first and only write the account down if it opens. A wrong address or a wrong password leaves **nothing** behind — not a line, not a half-created account.
```mermaid theme={null}
flowchart TD
A["“ADD AND CONNECT”"] --> B{"An address
and a password?"}
B -->|no| R1["Refused straight away
— nothing is written"]
B -->|yes| C{"Does Vestiaire accept
the credentials?"}
C -->|no| R2["The window stays open with the reason
— nothing is saved"]
C -->|yes| E["“Account added and connected”
— good for 30 days"]
style E fill:#1f6f43,color:#fff
style R2 fill:#7a4b00,color:#fff
```
On a refusal the window **stays open**, headed “Adding refused”, and the field at fault is marked so your eye goes to it — the address, or the password. You correct and try again without retyping everything. The password is wiped from the window as soon as it has been sent.
### What can refuse an addition
Every one of these leaves your list exactly as it was.
| Situation | What you read |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Address left empty | “Address required.” |
| Password left empty | “Password required.” |
| Vestiaire does not know the address | “Vestiaire does not know this address. Check it — it is the address of the Vestiaire account, not necessarily the same as your Vinted one.” |
| The password is refused | “The password is refused for this address. Check it, then try again.” |
| The refusal names nothing | “Vestiaire refused these credentials. We could not tell whether it is the address or the password: check both.” |
| The marketplace says nothing at all | “Vestiaire did not answer — `{detail}`. Nothing has been saved; try again in a moment.” |
**“Vestiaire did not answer” is not “Vestiaire refused”.** The first is a silence, the second is a verdict. On a silence, wait a moment and try again — nothing has been saved. On a verdict, go and check the credentials on Vestiaire itself before retrying.
### Once it is in
You read “Account added and connected — `{name}`”, the list is re-read, and the new account is selected with its page open — on a phone, the screen switches to that page. From then on the account appears in the list under the name you gave it, or, failing that, under its e-mail address **in clear**; failing both, “Unnamed account”. Its picture is the one Vestiaire holds, or its initials — never a generic face.
The search field above the list only appears past four accounts, and it searches the name **and** the address.
***
## What rega keeps, and what it refuses to keep
| What we keep | In what form |
| ------------------------------------------ | ------------------------------------------------------------- |
| The e-mail address | In clear — it is how you recognise the account |
| The password | **Encrypted at rest**, with a fresh scrambling on every write |
| The account's Vestiaire identifier | Deduced at connection, never typed by you |
| The end date of the connection | **Read from the connection itself**, never guessed |
| The username and the profile photo | Learned at connection; a name you type yourself always wins |
| Whether the account is active or set aside | A simple yes/no |
**No secret ever comes back out.** The account view sent to your screen carries no password, **not even truncated**. Your screen learns one thing about it and one thing only: whether there is a password on record.
The encryption is tied to the pair (your workspace, that address). A secret moved to another workspace no longer opens. That is deliberate.
Vestiaire serves us a great deal about the holder of an account. **We refuse to carry most of it**: the postal address, the postcode, the date of birth and the holder's own e-mail address are among the details the marketplace hands over and that rega does not transport. What is kept is what a buying tool needs to show you, and nothing else.
The account page never uses a word from the machine room either. No “session”, no “token”, no transport code — when a sign-in fails, what reaches your screen is a sentence you can act on, and the raw reason is dropped on the way.
***
## Reading an account's state
One state is decided for each account, in a fixed order, and the first line that is true wins. The list and the account page say it with **the same words** — one fact, one wording.
| Order | The state | What it means | Asks for a gesture |
| ----- | -------------------------------------- | ---------------------------------------------------------------------------- | ------------------ |
| 1 | “Disabled” | You have set this account aside. It stays on record and is used for nothing. | No |
| 2 | “Not connected” | No live connection, but a password is on record: our servers can open one. | Yes |
| 3 | “Not connected — password to be saved” | No live connection **and** no password. Nothing can reconnect it. | Yes |
| 4 | “Signed out — to be reconnected” | The connection no longer works. | Yes |
| 5 | “Connected — to be renewed soon” | Working, and near the end of its thirty days. | **No** |
| 6 | “Connected” | Working. | No |
**“Connected — to be renewed soon” asks nothing of you.** The account will buy this evening exactly as it bought this morning. Usable and expiring are two different things: an account whose connection runs out in two days is expiring **and** perfectly usable. Treating them as one would cut your buying off three days early.
The reverse case is treated the other way round: an account whose end date cannot be read is **assumed** to be near its end. When in doubt we warn rather than reassure.
### The connection panel
On the account page, the first panel of the second row is “CONNECTION”, with a “CONNECTED” or “NOT CONNECTED” pill and three lines.
| Line | What it says |
| --------------------------------- | -------------------------------------------------------------------------- |
| “State” | The state above, word for word |
| “Connection to be renewed before” | The day, written out in your language |
| — when the day is unknown | “date unknown — treated as near” |
| “Reconnects without you” | “yes — password on record”, or “no — the password will be asked for again” |
**“With no password on record, this account cannot reconnect on its own.”** That is the whole difference between an account that keeps working and one that stops on a date nobody watched. A Vestiaire connection does not renew itself the way a Vinted one does: there is nothing to refresh, there is a day after which buying stops dead.
***
## The five points that decide whether an account can buy
The account page carries a health strip, read as soon as the page opens. It is **five points and an AND — never a score**. Four points out of five green would read “almost ready” while the purchase fails; there is no such thing as almost.
Each point holds one of three labels — **“Ready”**, **“To watch”**, **“Missing”** — always the word **and** the colour, never the colour alone. A point that is not green also carries a “Fix →” button, which scrolls the page down to the section where the gesture is made; a point at “Ready” carries none, because there is nothing to go and fix.
**The order of the points is the order in which you unblock them**, and that is not decoration: a card is worth nothing without a connection, and a pick-up point makes no sense without a delivery method.
**Connection → Delivery address → Saved card → Delivery method → Pick-up point.**
The overall verdict takes one of four values, word for word: “This account can buy”, “This account will not buy”, “Account not checked yet”, and “Checking the account…” while the reading is under way. Under it sits a line of detail, which is a different sentence again: “Everything is in place: address, card, delivery method.” when the five are green, “Everything is in place. `{n}` points need watching.”, “One thing is missing: `{what}`.”, “`{n}` thing(s) are missing.”, or “Run a check to find out what is missing.” The button underneath reads “Check again”.
**Reading the list of accounts reads nothing from the marketplace.** In that mode the address and card points show “Not checked” — they have not been asked, and writing “Ready” there would be a guess. Opening an account's page is what asks.
A point worked out without a fresh reading is marked as such: “Inferred from what we knew — not checked again.” And a point left unknown blocks the verdict: an incomplete health check never passes for a complete one.
Three behaviours of that strip are worth knowing, because each of them looked like a bug before it was measured:
Those two lists are not the same one. With a full basket, a perfectly equipped account offers three payment methods; with an empty basket, the same account offers **none at all**. Reading the second list would declare a healthy account cardless every time its basket happens to be empty.
Vestiaire keeps serving it with a healthy status. The expiry is therefore worked out **here**, from the date on the card, rather than taken on trust — hence the values “Card expired” and “Expiry date unreadable”. It is not the only point where we set the marketplace's own answer aside: the delivery address is another, because Vestiaire names a different chosen address depending on where you ask it.
If the account's payment family is PayPal, demanding a card would manufacture a shortage that does not exist. “Not applicable” is a green light of its own kind, not a gap.
The connection point itself takes one of nine values. They are worth reading as a list, because the gesture is different every time:
| What the point says | What has happened |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| “Connected” | Asked, and it can buy |
| “To renew soon” | Working, near the end of its thirty days |
| “Not checked” | Nothing has been asked yet — the common case on a fresh account |
| “Check not possible” | The marketplace did not answer. **Not a refusal** |
| “Disconnected” | No live connection; the password is what opens one |
| “Connection expired” | The thirty days ran out, and the page names the day |
| “Connection refused” | The marketplace turned the connection down at payment time |
| “Account deactivated” | You set this account aside |
| “Access not allocated” | The account is not yet fitted with the access it needs. The page tells you what to do: create it again, or ask support |
**“Check not possible” is not “Connection refused”.** Confusing the two would have you reconnecting a healthy account during an outage — and a burst of sign-ins is the surest way to get an account locked. When the marketplace says nothing, the right gesture is to wait.
***
## A connection can be whole for browsing and refused for buying
This is the measured trap of this whole page. Two real connections were measured; **the older of the two was accepted on the browsing pages and refused on the buying pages**, with nothing else changed. So “the connection has not expired” does **not** mean “this account can pay”.
Everything follows from that:
* A freshly connected account shows **“Not checked”**, never “Connected”, on its connection point. The only green we accept there is one obtained by asking a buying page.
* The **“Check”** button exists for exactly this. It sits at the top of the account page whenever the account is usable, and it asks a page of the sensitive family — the least intrusive of them: it reads nothing of your basket and writes nothing. The same gesture is in the “More actions” menu, as “Check this account”.
* Its verdicts are toasts: “This account can buy — `{name}`”, or “This account will not buy — `{detail}`”, falling back to “cause unknown” when the marketplace names nothing.
* When the account is **not** usable, that button is replaced by “CONNECT” — “CONNECTING…” while it runs, then “Connected — `{name}`” or “Connection refused”.
**A check is a gesture, not a background habit.** It does not replace what the connection panel already tells you — it answers a different question. The end date tells you when the connection stops; the check tells you whether it works **for paying**, today.
**Refused credentials set the account aside instead of being retried.** You read: “Credentials refused — `{name}`. The account has been set aside: retrying every ten minutes would get it locked.” That is the product protecting the account from you and from itself.
And when a sign-in fails for any other reason, the raw technical reason is deliberately **not** shown. You read: “The last sign-in did not go through. Reconnect this account.” The detail behind it names nothing you could act on.
***
## Thirty days, and what renews them
| Fact | Value |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| How long a Vestiaire connection lasts | **30 days exactly** — measured on a real connection |
| Renewal along the way | **None.** The marketplace offers no way to refresh a live connection |
| When the account page starts warning | **3 days** before the end |
| Who reopens it | Our servers, on their own, **before** the end — and only for an account that has a password on record |
Reconnecting by hand, from “Reconnect this account” in the “More actions” menu, does the same thing at the moment you choose.
**With no password on record, nothing renews.** The account works until its last day and then stops buying — and there is no message at that moment, because nothing failed: the connection simply reached its end. This is the single strongest reason to save the password when you add the account, which is also why the window insists on it.
Two behaviours protect the account itself:
* **Refused credentials are never replayed.** The account is set aside on the spot, and you are told so. Retrying a wrong password on a schedule is how accounts get locked.
* **Anything that is not a refusal is retried** later, and only reported to you when the end date is approaching.
That upkeep runs **on our servers**. It does not matter whether your browser is open, or which filters you have running. Your accounts are looked after whether or not you are hunting.
***
## What Vestiaire tells us about the account
The account page carries a panel titled **“MY VESTIAIRE ACCOUNT”**. It reads nothing until you ask — the button says “See”, then “Read again” — and at rest it announces what it will contain: what Vestiaire knows about this account, from purchases and sales to followers, how long it has been a member, and the welcome voucher if there is one.
While it works it says “Reading the account…”. If the marketplace answers with nothing: “Vestiaire said nothing about this account. Try again in a moment.”
What comes back: the username, first and last name, profile line, photo, and then the counters — purchases, sales, on sale, wished for, followers, following, liked items — plus “Member since”, “Country of the account”, “Account level”, “Account type”, “On the buying side”, “On the selling side”, and any badges the marketplace grants.
| What you may read | What it means |
| --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| “Vestiaire gave no figures for this account. This is not an empty account: it is something it did not tell us.” | The marketplace served no counters at all |
| The “ON HOLD” pill | The account is paused **at Vestiaire** |
| “Picture up to date” / “No picture known — the initials stand in” | On the smaller “PROFILE” panel, next to a “Refresh” button |
**A missing counter is never shown as “0”.** “No sales” and “we were not told” are two different facts, and only one of them is about the account. Everywhere in rega, an absent figure stays absent — and what does not exist on Vestiaire is absent rather than shown at zero. That is why this account page has no trust panel: the marketplace publishes no score, and an empty score panel would be an invention.
An account on hold carries the explanation with it: “This account is on hold at Vestiaire. While it is, its listings are no longer visible there — switch the hold off from Vestiaire.” It is not something rega can lift for you.
### The welcome voucher
The panel shows it under “Your welcome voucher”, with its threshold — “from `{amount}` of purchases” — a “Copy the code” button that answers “Code copied — `{code}`”, and a link to “Read the terms at Vestiaire”. When there is none, it says so as a result rather than as a fault: “No welcome voucher on this account at the moment.”
**The amounts are copied exactly as Vestiaire writes them** — “100 €”, “10 %”. Reformatting a voucher would mean inventing a value we did not compute.
### The four details you can correct
Exactly four, and the window says why: “These four details are the ones Vestiaire lets you change. The rest — country, sign-up date, statistics — belongs to it and is changed on its site.”
From the “Correct” button of the panel.
“DISPLAY NAME”, “FIRST NAME”, “SURNAME”, “PROFILE LINE”. Nothing else on that panel can be changed from here.
The marketplace answers without saying what it stored. So rega says what it knows and nothing more — that your details have been sent — and it says just as plainly when the correction was turned down. It never pretends to have read them back.
***
## What an account carries: the three gestures
The gestures themselves are not made on this screen. They are made **in the feed**, on the dashboard: Vestiaire listings arrive there among your Vinted ones, on the same cards, each one labelled with the marketplace it came from — and every card carries a “BUY” button, a “♥” for the watchlist and a “More actions” menu.
Above the feed, a selector offers **“Both” / “Vinted” / “Vestiaire”** — “Show listings from both marketplaces”. It changes only what is painted: the radar keeps detecting both, and automatic buying keeps working on both, whichever one you are looking at.
“Add to Vestiaire favourites”, from the card's “More actions” menu or from the item panel. It answers “In the Vestiaire favourites of `{account}`”.
“Make an offer on Vestiaire”, from the same menu. The window confirms the amount **and the account it went out from**.
“BUY” opens “BUY ON VESTIAIRE”: prepare, then pay once your bank has confirmed. The account is held for the whole of it.
Every one of them goes out from **one named account**, never from “the first usable one”, and the confirmation names it. With no usable Vestiaire account, the favourite is refused with: “Cannot add to favourites — no usable Vestiaire account. Connect one in Vestiaire › Accounts.”
**That last sentence names a screen that is no longer in the menu.** There is no “Vestiaire › Accounts” to go to: the path is **Accounts → the Vestiaire door**. The wording is on our list to correct.
**A heart cannot be taken back from rega.** The tooltip says it before you click: “Hearts the listing from your Vestiaire account. No effect if it was already there, and it cannot be removed from rega.” The button label never flips to “remove”, because the marketplace never tells us whether the heart was already there — and a button that fails silently is worse than an absent one.
***
## One basket for the whole account
On Vestiaire the basket does not belong to a listing, it belongs to **the account**. Everything that follows comes from that one fact.
**One purchase at a time, per account.** Not per item — per account. The refusal names the reason rather than blaming the marketplace: “A purchase is already under way on this account. Wait for it to finish: on Vestiaire, two purchases started at the same time from one account cancel each other out.” The gesture expected of you is to wait, not to start again.
A payment left waiting keeps holding the account. A banner brings it back to you **at the very top of the dashboard**, with its amount — titled “Your bank is waiting for your confirmation”, or “A Vestiaire payment is under way” when it is the marketplace that has not answered. Underneath, the reason: “While this payment waits, no other Vestiaire purchase can go out: the basket is shared across the account.” The banner is only there while something is waiting.
Two buttons: **“Resume”**, and **“Cancel payment”**, whose tooltip states both halves of what it does: “Closes this payment and empties the Vestiaire basket, so the account can buy again. The item will no longer be reserved for you.”
**This is not a theoretical problem.** It happened on a real account: a payment sat waiting on its bank step — a **€97** dress, **€116.52** in the basket — because a bank confirmation had been interrupted two hours earlier. That single stuck line stopped the account from opening any other Vestiaire payment **and** stopped its pick-up point map from opening, because both need the same basket. There was no way out of it from the product; there is one now.
The same shared basket explains two refusals you may meet on the pick-up point map:
* “This account is already preparing a purchase. Finish it before opening the pickup-point map — both share the same basket.”
* “Your Vestiaire basket already holds an item. Empty it to display pickup points: the map needs the basket, and we will not discard your choice.”
**A payment whose confirmation has already gone cannot be cancelled.** Up to and including the bank step, cancelling is offered and safe. Once the confirmation has left, the money may have moved: “This payment has already been requested from the bank: rega can no longer cancel it. Check your Vestiaire orders before buying this item again.” The full sequence is on [Buying on Vestiaire](/vestiaire/buying).
### The card, and the two ways of holding it
The account page has a “PAYMENT METHODS” panel. An account with no card detects and cannot buy, and it says so twice over: “This account has no card it can pay with.” and “Until a card is on record, this account detects items but cannot buy anything.”
The card itself is registered **with Vestiaire** at the first purchase: “A card is saved with Vestiaire at the first purchase: rega presents it at payment, then Vestiaire keeps it and shows it here.” From then on the marketplace only asks for its security code at each purchase — and that is what the lighter of the two ways keeps, and only that: “rega keeps this card's security code, and nothing else: the number stays with Vestiaire. That is all it takes to pay.”
The heavier way keeps the whole card, number and security code alike, both encrypted, under the heading “CARD KEPT BY REGA”: “rega keeps this card for this account's purchases.” Which of the two is open to you is decided for the whole installation and not on this screen; where it is closed, the panel says so and explains that opening it is the service owner's decision, not a setting you can flip.
Entrusting the security code is what lets the account prepare a purchase on its own — basket, delivery, card — leaving you the single step your bank asks for. **It does not make the purchase happen without you**: on the card we measured, the bank asked for its confirmation **four times out of four**. That demand comes from the card's issuer, not from the marketplace — another card may well be exempt.
***
## Setting aside, and removing
Two different gestures, both in the “More actions” menu of the account page, and only one of them is final.
| Gesture | What it does |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| “Set this account aside” | “It stays on record but will not be used for any purchase.” The state becomes “Disabled”, and the page carries a “SET ASIDE” pill |
| “Reactivate this account” | “It becomes usable for purchases again.” |
| “Remove this account from rega” | The account goes, along with whatever card rega was keeping for it |
**Removing asks you nothing.** There is no confirmation window on this page: the moment you choose “Remove this account from rega” in the menu, the account is gone and you read “Account removed — `{name}`”. Nowhere else in the product is a removal this direct — read the name on the page before you open that menu.
Whatever rega held for that account is erased with it, security code included. A secret that outlived its account, with nothing left able to reach it, would be the worst kind.
**Set aside first, remove later.** An account you may come back to is better set aside: it is out of every purchase, it keeps its history and its name, and one click brings it back. Removing is for accounts you will not use again.
***
## Our advice
The name field is optional and it is the one you will regret leaving empty: it is what appears in the list, on every confirmation, and in the toast that tells you an offer went out.
**The move**: a name like `Main` or `Backup` beats an address you have to read twice. You can still do it later, from “Name this account”.
A connection can be whole for browsing and refused for buying — measured on a real connection of ours. What the list shows is not necessarily recent; the check is.
**The move**: on the account you are about to hunt with, click “Check” and insist on “This account can buy — `{name}`”.
They are an AND. Four out of five is not “almost ready”, it is an account that will fail mid-race on an item the radar had found for you.
**The move**: unblock them in the order they are printed — connection, address, card, delivery method, pick-up point. Each one carries the gesture and the “Fix →” that takes you there.
“Check not possible” means the marketplace did not answer. It is not a refusal, and reconnecting on it re-signs a healthy account for nothing — a burst of sign-ins is the best way to get an account locked.
**The move**: wait, then check again. Only “Connection refused” or “Connection expired” call for a reconnection.
An account whose password is rejected is set aside immediately and never retried: “retrying every ten minutes would get it locked”.
**The move**: change the password on Vestiaire, save it here, then reactivate the account. In that order — reactivating first only queues another refusal.
While one waits, that account can neither buy anything else nor open its pick-up point map — the basket is shared. The banner shows it with its amount, at the top of the dashboard.
**The move**: “Resume” if you intend to go through with it, “Cancel payment” otherwise. Cancelling also empties the basket, and it says whether that worked.
Vestiaire has no notion of roles, so nothing in the product stops one account from doing everything. Your names are the only place that distinction can live.
**The move**: if you keep a second account as a fallback, name it as one. It is what you will read in a hurry, mid-race.
Removal is the one gesture on this page with no confirmation behind it.
**The move**: check which account the page is showing — the name is in its header, next to the marketplace — and only then open the menu.
***
## What surprises people
The marketplace lives inside the product: its listings in the feed, its filters in the filter list, its accounts behind a door in Accounts. Nothing in the menu is named after it, and nothing needs to be.
Vinted does; Vestiaire does not. Here it is one window, three fields, one button — and the password is required.
Nothing has asked a buying page yet, and the connection's validity does not answer that question. Showing green there would be a guess dressed up as a fact.
It is information. Three days before the end, we start saying it; the account keeps buying until its last day.
Not knowing is not the same as being fine. When the date cannot be read, we warn rather than reassure.
On an account whose payment family is PayPal, asking for a card would invent a gap. That value is a normal outcome, not an error.
The menu item does it. The toast tells you afterwards which account it was.
The security code, and the number too when rega kept the whole card. Otherwise those secrets would outlive the account with nothing left able to reach them.
The screen only learns that one exists. That single flag is what the “Reconnects without you” line is built on.
Postal address, postcode, date of birth, the holder's own e-mail address: all served by the marketplace, none carried by us. A buying tool has no use for them.
***
## What this does not do yet
We would rather write it here than let you find out halfway through.
Setting a heart works; listing them does not. The panel that showed them was taken off the account page, and the feature is moving elsewhere in rega.
No gesture in rega takes one back. We would rather not offer a button that could fail silently on the wrong item.
Offers go out and are recorded, but no screen lists them yet. An offer we could not record **still went out**; never replay it.
The Orders screen knows nothing of this marketplace: a Vestiaire purchase will never appear there, whatever a notification may suggest.
Adding a Vestiaire item to your watchlist sets no heart on the marketplace. The two gestures are separate, on purpose: the identifiers of the two marketplaces overlap, and a heart sent to the wrong one would land on a real, unrelated listing.
With no password on record, it runs out and buying stops. There is no failure to report at that moment, so there is no message — which is exactly why the connection panel says “no — the password will be asked for again” from the day you add the account.
***
## Where to go next
Why the work is not the same here as on Vinted, and what one shared watch means.
The floor, where it comes from, and why it rises to your amount and never comes back down.
The two steps, the shared basket, and what an item really costs once the marketplace has added its lines.
Every criterion, what it costs, and what happens when two of them contradict each other.
The feed both marketplaces share, the place selector, and where a purchase starts.
The two doors, the full account page, and which account pays for what.