Repository navigation
[FEATURE] next level - ECommerce best pic Quality for money | Print on Demand Implement #48
Description
Describe the solution you'd like
Someone The implementation of getting the best Quality for 2€ for example. The free picture just hast a lower dpi.
I would like to have an implementation for ecommerce or Print on demand products.
For example: a customer of mine is seeing a pretty cool picture of him in my gallery: or of a friend of them. It would be a pretty cool present for christmas or birthday to just order it and in one week its already there. Such as hard covered pictures, a smartphone cover, something like that. (imagely has the whcc) In best case a company for delivering the whole word.
Something like scrapbook but more complex.
Just got some ideas i would like to share with you.
Thank you for your work.
Gian Lieberum
Activity
the-luap commentedon Nov 13, 2025
I think the first one is possible for me to implement but for the print implementation I don't think that it will make sense at the moment. If we find someone who wants to implement, I am more than happy to help, but for now I will not consider that option.
But many thanks for sharing Ideas!
Luca-Timo commentedon May 14, 2026
Hey @gianlieberum-creator — thanks for the detailed write-up.
Quick context on where we are right now: we're building out the CRM side of picpeak on the
Luca-Timo/picpeak/feat/crmbranch, admin-side quotes, invoices with a manual cancel-and-reissue flow, a payment-check email workflow (admin gets an email with three buttons after the due date: paid in full / partial / not paid), and a tax / Steuer report for exporting to your accountant. All payment is traditional invoice → bank transfer; there's no payment processor, no automated checkout, no fulfilment integration.Your print-on-demand idea is out of scope for this iteration, it's a different shape of feature (customer-facing storefront + fulfilment provider integration + variable-quality serving) than what we're shipping now. That said, I'd like to understand what you'd actually want, so when someone (you, me, anyone) picks it up it isn't designed in a vacuum.
A few specific things that would help:
No pressure to fully scope it, partial answers move things forward.
icelessgo commentedon Oct 23, 2026
Adding an Ireland-based wedding photographer’s perspective, as I’ve been testing a private PicPeak gallery shop covering photographic prints, canvas and additional wall-art products. It is an isolated pilot, with end-to-end payment testing and physical product validation still outstanding.
The album work is a separate stream, noted in my comment on #1924. Related draft PR #2222 covers the shared product configurator and CRM integration; it is not the full album editor. My working private Album Studio supports Graphistudio and Saal, while the full native album port remains unfinished. Saal successfully imported the cover and interior PDFs together, but physical quality is still unverified.
Picking up the questions above:
1. Print partners
My current choice is manual Saal fulfilment for prints/canvas and individually verified additional products. I have not established a supported public Saal ordering API.
The API research was filtered around genuine 10×15 cm / 4×6 photographic prints, canvas, Ireland delivery and suitable production/dispatch arrangements:
These are suitability findings for my Ireland-based requirements, not general exclusions for PicPeak users elsewhere.
2. Manual fulfilment is useful for v1
The pilot prepares the approved artwork, a supplier pack and a private studio order sheet containing cropped thumbnails, source filenames, prepared-file references, dimensions, finishes, quantities and delivery details. That allows the studio to reconstruct or verify the order if bulk import fails. A payment receipt alone is not detailed enough.
Artwork approval, payment and studio release are separate steps. A paid order does not automatically buy from a lab, and dispatch is recorded explicitly. I’m comfortable starting with this workflow and reassessing automation as volume grows.
3. Payment
For small print purchases, my preference is card checkout. Stripe Checkout is implemented as the pilot’s payment route, with full payment testing still pending. Revolut was considered but has not been integrated.
PicPeak retains the basket, specifications, prices, artwork and order record. Checkout collects payment and the remaining contact/delivery details once. A verified CRM client’s email can be reused; a shared gallery password does not identify the buyer. An invoice/bank-transfer route could also fit this order model.
4. Customer journey and screenshots
The shopping experience draws on Zenfolio, with Pixieset and SmugMug also reviewed:
These screenshots use sample artwork and artificial test prices. The space previews are illustrative, not supplier manufacturing previews.
Shopping stays alongside the selected gallery photograph:
Optional “Show in space” preview:
Per-photo basket quantities and crop editing:
A shared admin catalogue supplies all enabled galleries, including retail prices, delivery thresholds and quantity/mixed-product bundles. Adding a priced item makes it available in the pilot shop; live availability requires its lab specifications to be approved:
5. Quality and practical lessons
Paid digital downloads are a separate requirement from physical printing. I would define digital tiers through actual pixel dimensions and usage rights; changing DPI metadata alone does not create a different-quality image.
For physical products, nominal dimensions are insufficient: trim, bleed, canvas wrapping and colour handling need product-specific verification. Even approximately 3:2 formats can need cropping. Supplier production templates also do not necessarily include reusable product mockups.
Approved orders need to retain their exact artwork, source version, specifications and prices when the gallery or catalogue changes.
My next focus is payment testing, exact lab-profile checks and physical product validation before a controlled rollout. A gallery storefront with dependable order records and manual supplier export would already be a useful first milestone.
If there is interest from the maintainers, I’d be open to implementing a Prodigi API integration, or another recommended print lab with suitable products and regional fulfilment. I’d be happy to agree the scope and integration approach here first, with automated lab submission remaining an optional fulfilment route.
Luca-Timo commentedon Oct 25, 2026
Thanks a lot for the detailed write-up and the research, @icelessgo! The supplier comparison and the lessons on trim, bleed and frozen artwork are really useful.
On print services: as discussed before, we don't want picpeak to integrate one or two specific print labs. Every studio works with a different lab depending on country, products and quality, so a hard-wired Prodigi (or Saal, WHCC, …) integration would only help a small part of the users and would need ongoing maintenance for each provider.
What could work instead is a generic base setup the studio configures for its own print service, for example:
That said, this is a lot of work and not something we're planning right now. If you'd like to explore it, please sketch the scope here first. It should build on the #2222 catalogue rather than a separate product list, with no provider-specific code in core.
On payment: a Stripe integration is planned, but nobody is working on it at the moment. The direction so far is card payments only, with the fee absorbed by the studio and no card surcharge for the customer (surcharges aren't allowed under PSD2). We haven't looked at other providers like Revolut yet. And independent of any payment provider, the existing invoice path stays available: the order becomes a CRM invoice and the customer pays by bank transfer. If you or anyone else wants to build the Stripe integration, please open a new issue for it so we can agree on the scope there first.
icelessgo commentedon Oct 25, 2026
Thanks, this matches the direction I'd favour too: a reusable print-sales layer that each studio configures for its own lab, with no provider-specific implementation in core.
I have checked the current #2222 draft. It already provides the shared option/size library, CRM pricing and VAT, and frozen commercial specifications, so I would build on that rather than add another print catalogue or billing system.
Proposed first scope
One proposed boundary is to keep payment and preparation separate: clients can confirm their selected photos/crops and pay while full-resolution files are generated. That does not mean they approved unfinished production files. Fulfilment still needs verified settlement, matching completed files and a studio check. Required originals must survive gallery expiry while a paid order is being prepared; catalogue/source changes must never silently replace accepted artwork.
I would defer a generic supplier API harness until manual export establishes the contract. Later it could expose a versioned order/artwork/status boundary for external studio connectors, with controlled file access, authenticated callbacks and idempotent submission. Prodigi could be an external example if useful, without PicPeak maintaining provider-specific adapters.
Stripe should remain a separate native-invoice payment contribution, preserving bank transfer and the proposed card-only/studio-absorbed-fee direction. Albums likewise remain a separate selection/layout/proof work stream; neither album generation nor payment-provider integration should block the first invoice/manual-export release. The separate proposals are #2252 (native invoice payments) and #2251 (optional timestamp-first album drafts).
Feedback before implementation
I am seeking agreement on these boundaries before starting generic print-shop code. This is a scope proposal, not a maintainer delivery commitment.