The certificate lifecycle on Shopify: returns, resales, and deleted products

A certificate is a record, not a souvenir

Here is the pattern behind most certificate implementations: an order comes in, a certificate gets generated, everyone moves on. Issuance is treated as the whole job. That works right up until commerce does what commerce does. A buyer returns the piece and you want to re-sell that edition. A collector sells to someone else two years later. You retire a line and delete it from your catalogue. Each of those events changes what the certificate should say, and a setup that only handles issuance keeps saying the same thing regardless.

The timing data makes this concrete. About 30-50% of buyers scan their certificate within the first week, based on view-tracking data from Editioned-using stores. Many of the rest scan months later, typically when they resell or gift the piece. A large share of scans land exactly when the lifecycle events above have had time to happen, so the page that loads needs to reflect the edition's current state, not a snapshot of the day it shipped.

This is also the direction regulation points. The EU's Digital Product Passport under ESPR 2024/1781 treats the product record as living data, a federated registry with JSON-LD records reached by QR (GS1 Digital Link), rather than a write-once token. A record with no update path was never on the table.

Four events matter: issue, revoke, transfer, invalidate. Let's walk each one.

Issuance: the step everyone gets right

Issuance is the well-trodden part. In Editioned, you set an Edition Total per product and the editions generate immediately, each with its own verification token. When an order is placed, the next available edition auto-assigns to that buyer, and the certificate URL lands on the order as plain Shopify metafields so your own shipping email can carry the link (Editioned never sends email; here is why, and the exact fields).

The one detail worth auditing in any setup is the token itself. Editioned's verification tokens are cryptographically random, 10+ characters, with 2.8 trillion+ possible combinations, so knowing one certificate URL tells an attacker nothing about any other. That property matters for everything that follows: revocation and transfer both work by rotating the token, and rotation only means something if the token space is too large to enumerate. The cert integrity section has the math.

If hosted certificates are new to you, the certificate of authenticity on Shopify post covers the basics. The rest of this post assumes issuance works and asks what happens next.

Returns and refunds: revocation and token rotation

Say you sell a numbered run of 25 and edition 7 comes back as a return. You inspect the piece, restock it, and eventually sell it to a second buyer. The question almost no DIY setup asks: what does the first buyer's certificate link show now?

If the answer is “a valid certificate for edition 7”, you have a problem. The first buyer still holds the URL, in their inbox, their screenshots, maybe a resale listing they never took down. Two people can now present the same edition, each with a page that renders as legitimate, and no third party can tell which of them actually holds the piece. One mishandled return is enough to make the scarcity claim on the whole run unverifiable.

The fix is revocation with token rotation. When a return or refund lands, Editioned revokes the edition and rotates its token, so the old URL stops resolving. When you re-sell the piece, the edition issues again with a fresh token and only the new buyer's link resolves. The old link is not “flagged as returned” in a database somewhere while continuing to render a certificate; it is dead.

Naive setups fail here in two directions. A DIY metafield-and-Liquid build usually has no revocation concept at all, because nothing connects the refund event to the certificate page. NFT-era apps have the opposite problem: the minted token sits in the first buyer's wallet, and getting it back requires their cooperation. The full returns flow, including how revoked editions re-enter the pool, is covered in the numbered editions guide.

Resale: transfer, not a forwarded link

A resale is the good version of the same problem. The piece changes hands legitimately, and the certificate should follow it, without leaving a working copy behind.

Forwarding the URL does not achieve that. A URL is not ownership; it is access, and access copies for free. If the seller keeps the link after the sale, both parties hold the same “proof”, which is the returned-edition problem again, just with more goodwill involved.

Editioned handles resale with email-bound ownership and one-time claim links. The current owner triggers a transfer, the new owner receives a claim link that works exactly once and binds the certificate to their email address, and the token rotates so the seller's old link goes dead. The original order stays on the record, so the provenance history reads the way a provenance history should: issued to the first buyer, transferred to the second. The step-by-step walkthrough is in our post on transferring a certificate of authenticity at resale.

For jewellery and other pieces that resurface at resale years after purchase, this event is where the certificate earns its keep. It is also the event most setups have no answer for: a paper certificate transfers by handing it over, which proves possession of the paper, not continuity of the record.

Deletion: why HTTP 410 beats a silent fallthrough

Products get deleted. Lines get retired, test products get cleaned up, catalogues get restructured. What should a certificate URL do when its product no longer exists?

The dangerous answer is: whatever the platform does by default. DIY certificate pages built as Liquid templates typically key off the product handle. Delete the product and the URL might 404, or, worse, resolve to something else entirely: a different product that later inherited the handle, a generic template rendering with empty fields, a redirect to the homepage. A certificate page that silently starts describing a different product is worse than no certificate at all, because it still looks like verification.

The correct behaviour is HTTP 410 Gone. Where a 404 says “nothing here, no idea why”, a 410 says the resource existed and was deliberately removed, and clients should not expect it to return. It is an honest, machine-readable statement of invalidation. When a merchant deletes a product, Editioned returns 410 on every certificate URL for that product, with a “Certificate no longer valid” page for the human reading it. A buyer, or a resale platform's intake scanner, gets a provably invalid result instead of a confusing dead end or a wrong answer.

Here is the whole sequence in under 30 seconds, on a real store:

What resale platforms check at intake

Resale platforms are the certificate's toughest audience. StockX, Vestiaire, The RealReal, and dozens of niche platforms now scan certificates before accepting consignments, and the intake check is unsentimental: does the URL resolve, does the page match the physical piece, and does the record look like the merchant's own rather than a screenshot.

Three details decide how that scan goes:

• Where the URL points. Editioned certificate pages live on the merchant's own domain, at your-store.com/apps/provenance/..., and are tamper-evident. That reads very differently at an intake desk than a link to a third-party SaaS domain that may or may not exist next year.
• Whether the page is current. This is where the lifecycle work pays off. A revoked edition's URL does not resolve, so a returned-then-relisted piece cannot ride on the first buyer's link. The authenticator does not run a separate revocation check; the ordinary scan surfaces it.
• Whether the QR is where the authenticator expects it. The cert PDF is DL card size, prints on standard 210x99 mm cardstock, and carries the QR code, the masked verification token, and the edition number on the back, so the piece travels with an intake-ready card. Where to place QR codes, and how GS1 Digital Link changes the answer, is covered in our QR code certificate post.

For the platform-by-platform view of how sneaker and streetwear intake actually works, see resale authentication for sneakers and streetwear.

The lifecycle at a glance

If you are evaluating a certificate tool, a DIY plan, or a per-mint service, this table is the audit. Ask what happens at each row and accept nothing vague:

Issuance is table stakes. The other rows are where certificate setups quietly diverge, and where the lifecycle problem flagged in our complete guide to Shopify provenance certificates gets decided.

Frequently asked questions

What happens to the certificate when a buyer returns a piece?

With Editioned, the edition revokes and its verification token rotates, so the old certificate URL stops resolving. If you restock and re-sell the piece, the edition issues again with a fresh token and only the new buyer's link works. In a setup without revocation, the first buyer's link keeps validating an edition they no longer own.

Can a certificate be transferred to a new owner?

Yes. Editioned uses email-bound ownership with one-time claim links: the new owner claims the certificate once, it binds to their email address, and the token rotates so the seller's old link goes dead. The original order stays on the record, so the provenance history remains complete.

What does HTTP 410 mean, and why not just a 404?

HTTP 410 Gone tells browsers, crawlers, and verification tools that the resource existed and was deliberately removed, and that they should not expect it to return. A 404 is ambiguous: it could be a typo, a moved page, or a temporary glitch. For a certificate that difference matters, because a 410 is a provably intentional invalidation rather than an unexplained dead link.

Does deleting a product break all my certificates?

No, only the certificates for that product, and they do not break so much as invalidate on purpose: each certificate URL returns HTTP 410 Gone with a “Certificate no longer valid” page. Certificates for every other product are unaffected. The underlying data is open JSON-LD, so you can export records before removing a product if you want an archive.

Do resale platforms actually check revocation?

Not as a separate step, and they do not need to. Platforms that authenticate at intake, StockX, Vestiaire, and The RealReal among them, scan the certificate and check that the URL resolves and matches the piece. A revoked edition's token has rotated, so its old URL simply does not resolve, and the standard intake scan surfaces that on its own.

Where to go next

Each lifecycle event above has its own deep dive: