Shopify line item properties prijs: tekst op de order, niet in checkout

Veel Shopify-shops plakken een extra veld in hun productformulier: `properties[Breedte]`, `properties[Gravering]`, `properties[Bestand]`. De tekst landt netjes op de orderregel. Wat niet gebeurt: de checkout-prijs past zich aan. Dat is het kernprobleem achter Shopify line item properties prijs — merchants denken dat een thema-input een prijslogica is, tot de eerste klant van 80 cm hetzelfde betaalt als iemand van 240 cm.

Shopify zelf beschrijft line item properties als *custom information* die je of de klant aan een regel hangt, via een input in het productformulier of via de Ajax Cart API. Zie de Liquid-documentatie bij `line_item.properties`. Handig voor fulfillment. Geen vervanging voor variants, formules of een cart transform. Als je maten, toeslagen of een prijs per m² live wilt laten rekenen, hoort daar een calculator bij — bijvoorbeeld Options Price Calculator.

Na dit stuk weet je wat properties wél doen, waarom JavaScript op de productpagina geen veilige prijs is, en hoe je velden plus formule inricht zonder extra SKU’s.

Wat line item properties officieel zijn

In Liquid vang je ze zo:

```liquid {% form 'product', product %} <label for="engraving">Gravering</label> <input type="text" id="engraving" name="properties[Engraving]"> {% endform %} ```

Shopify bewaart de naam–waardeparen op de cart line. Ze verschijnen in winkelwagen, checkout en admin-order. Prefix je de key met een underscore (`properties[_internal]`), dan blijft het veld verborgen voor de klant maar wél beschikbaar voor je proces. In e-mailnotificaties kun je ze uitlezen via `line.properties` — Shopify noemt dat expliciet in de variabelenreferentie voor notificaties.

Dat is de hele belofte: informatie meenemen. Geen prijs, geen voorraad, geen SKU. De betaalde bedragen blijven die van de gekozen variant.

Hetzelfde geldt voor cart attributes (`attributes[...]`): die hangen aan de hele order, niet aan één regel, en wijzigen de variantprijs evenmin.

Waarom shops dit als prijsoplossing gebruiken

Het voelt logisch. Je hebt geen vierde native option over, en continue maten passen niet in een dropdown. Volgens Adding variants mag een product maximaal drie options hebben en 2048 variants bevatten. Die variantcap ging op 15 oktober 2025 omhoog voor alle merchants (Shopify-changelog); de drie-optiegrens bleef staan. Een extra tekstveld in Liquid is dan de snelste workaround.

In de community zie je het patroon terug. In Custom price for my product at runtime wil een merchant hekwerk op eigen hoogte en lengte verkopen: line item properties + JavaScript om de prijs te tonen. De antwoorden zijn consistent: de Ajax API accepteert geen custom prijs; zonder extra laag blijft de variantprijs staan. In How to Add Extra $10 Based on Custom Form Selection lukt het wél om een keuze als property mee te sturen — maar de extra tien euro komt niet op de regel.

Wat shops vervolgens proberen:

1. Prijs alleen in de browser updaten. De klant ziet €187, de winkelwagen toont €49. Dat is geen “glitch”; de server heeft nooit een andere prijs gekregen.

2. Een verborgen property `_price` meesturen en hopen dat checkout die leest. Checkout leest de variant.

3. Een los “toeslag”-product in de cart gooien. Technisch werkt het, maar de klant ziet twee regels en je kortingen/verzending worden rommelig.

4. Elke cel als variant. Dat botst opnieuw op drie options en een catalogus die je niet wilt beheren. We schreven eerder hoe prijs op eigen maat zonder S/M/L-matrix kan.

Line item properties zijn dus geen bug. Ze doen precies wat Shopify belooft — en dat is minder dan een prijscalculator.

Waarom “even een scriptje” de checkout niet redt

Zelfs als je de getoonde prijs op de productpagina mooi laat meebewegen, blijft de cart-API een `variant_id` + `quantity` + optionele `properties` verwachten. Er is geen veld `price` dat een thema mag zetten. Dat is bewust: anders kan iedereen de checkout ondermijnen.

Om de betaalde prijs wél te laten afwijken van de catalogusprijs, heb je een server-side laag nodig. In de Shopify-wereld is dat tegenwoordig een app met een cart transform of een vergelijkbare validatie, niet een Liquid-snippet. Community-threads over runtime-prijzen eindigen daar steeds: theme-code verzamelt de input, een app past de regelprijs aan en houdt die consistent tot de order. Zelf een Function schrijven is geen merchant-workflow — en op veel plannen is een ruwe `update`-operatie bovendien beperkt.

Wat je wél als merchant wilt: velden die de klant begrijpt, een formule die je zelf onderhoudt, en een prijs die op de productpagina, in de cart én in checkout hetzelfde is.

Hoe Options Price Calculator velden én prijs koppelt

Options Price Calculator is gebouwd voor precies dit gat: onbeperkte productopties (dropdowns, swatches, getallen, checkboxes, tekst, file upload) plus een formule, zonder extra varianten. De app is Built for Shopify en landt als theme app extension op de productpagina — geen handmatige `properties[...]`-hack in je theme.

In de formula builder worden veldkeys variabelen. Een gravering met toeslag is geen verborgen `_price`, maar een checkbox of tekstveld met een numeric value:

``` product_price + engraving ```

Een maatwerkpaneel:

``` product_price + (width * height) ```

Of met setupkosten, zoals in de docs:

``` product_price + 25 + (width * height) ```

Een checkbox die niet is aangevinkt telt als `0`. Helpers als `Math.round` en `Math.ceil` mag je gebruiken. Conditional logic (if/then, minimumprijs, staffel bij `width > 200`) zit op het Premium-plan, net als live preview en een price breakdown. Claim die niet als gratis.

Belangrijk voor wie net een Liquid-veld heeft gebouwd: de app toont de prijs niet alleen in de browser. In de app-wide settings zit server-side price validation — de berekende prijs wordt gecontroleerd, zodat een aangepaste frontend de checkout niet kan ondermijnen. Dat is het verschil met een `innerText` op de productprijs.

Op de order komen de ingevulde opties mee. Optioneel voeg je die data toe aan de orderbevestiging, zodat werkplaats en klantenservice dezelfde maten zien als de checkout. Native properties doen dat informatiedeel ook; ze missen alleen de prijshelft.

Voorbeeld: raamfolie met “gratis” thema-velden

Stel: je verkoopt raamfolie. In het thema staan twee number inputs, `properties[Breedte_cm]` en `properties[Hoogte_cm]`, plus een dropdown `properties[Filmtype]`. Fulfillment is blij: de snijtafel ziet 142 × 96 cm, silver. De klant betaalt de variantprijs van het kleinste staal, €29.

Wat er misgaat is niet de input, maar het ontbrekende contract tussen input en geld. In OPC vervang je die drie Liquid-velden door:

1. Number fields `width` en `height` (cm, met min/max).

2. Dropdown `film_type` met multipliers (bijvoorbeeld 1 / 1,25 / 1,6).

3. Formule `product_price + (width * height / 10000 * 45 * film_type)` — 45 euro per m², schaalbaar per folie.

Houd echte voorraad (drie foliesoorten die je op rol legt) als Shopify-variants. Alles wat geen SKU is — maat, montagezijde, snijverlies — blijft een optie. Meer dan drie keuzes is dan geen probleem; native options blijven gereserveerd voor wat je echt op voorraad houdt. Over die grens schreven we eerder bij Shopify meer dan 3 opties.

Zelfde patroon voor gravering, cadeauverpakking (`product_price + gift_wrap`) of een bestandsupload met handling fee.

Wat je nodig hebt om te starten

1. Installeer Options Price Calculator. Free plan: 20 uses (op een Shopify Develop-store altijd gratis). Starter ($9.99/mo) geeft onbeperkte opties, formula builder, metafields en meertaligheid. Premium ($14.99/mo) voegt conditional logic, font picker, live preview en breakdown toe.

2. Zet het app block op je producttemplate, onder de prijs en boven Add to cart — stappen in How to Add the Extension to the Product Page.

3. Bouw alleen velden voor wat géén voorraad-SKU is. Laat bestaande `properties[...]`-inputs uit het thema staan tot de calculator live is, haal ze daarna weg zodat je geen dubbele velden krijgt.

4. Schrijf de formule, test met previewwaarden, link de calculator aan de juiste variants (bulk kan later).

5. Zet server-side validatie aan en check één testorder: prijs in cart = prijs in checkout = prijs op de order.

Native variants blijven de bron voor voorraadbare combinaties. Line item properties blijven nuttig als je *alleen* een interne notitie wilt meegeven. Zodra er geld aan vastzit, hoort de input in de calculator.

Tot slot

Shopify line item properties prijs is een misverstand dat in bijna elke maatwerk-thread terugkomt. Properties bewaren wat de klant typt; ze herberekenen niets. JavaScript op de productpagina lost de checkout niet op. Extra variants lossen continue maten niet op, ook niet nu de limiet 2048 is.

Zet de velden in een formule, valideer de prijs server-side, en laat de klant afrekenen zonder offerte. Dat is precies waar Options Price Calculator voor is.