Hur reserverar ni varor folk lägger i kundvagnen?

[Dan]

Har ett litet problem som uppstår med alla betalsätt som ej sker direkt eller i egna plattformen, exempelvis kortbetalning och liknande när man slussas till tredjepart.

När man lägger en vara i kundvagnen hos oss reserveras den inte utan saldo dras ner när betalning sker.

När man kör en kortbetalning exvis har vi en lucka på cirka 1-5 minuter där någon kan beställa varan samtidigt (om sista exemplaret till exempel) och dra ner lagersaldot innan kunden med kortbetalningen är klar och den ordern reggats som betald.

Detta funkar bra om man alltid har mycket i lager eller få ordrar, men inte när man har större volym (har jag märkt nu).

Så hur jobbar ni med reservationer baserat på kundvagnar. Finns ju en del fällor att gå i här också och sårbarheter genom att tillåta reservationer. Kör ni X antal varor per kund som kan reserveras (för att undvika att någon blockar hela lagret) och någon specifik tid som reservationen gäller?

Eller finns det en bättre lösning jag inte tänkt på?

[Joel]

Detta problem har vi också, men det sker relativt sällan så än så länge har det inte prioriterats i att göra listan. När det väl händer är det dock riktigt drygt och det förstör ju inte bara för kunder utan även för vårt lager.

Enklast är väl som du säger att reservera produkterna ett par minuter och sedan släppa dem. Förslagsvis kanske du kan kolla hur länge sessionen hos din betalleverantör håller sig och justera din tidsram efter detta.

Ett tips kan också vara att bygga in någon form av anti-fraud i systemet så ingen lyckas reservera 90% av ditt lager

[Christoffer Tyrefors]

---

[Dan]

Ja, min spontana tanke var att vid tillägg i kundvagn eller i kassan för slutförande kolla om det finns några aktiva kundvagnar som redan har produkten i sig och har gått förbi kassan och då visa den som ”slut”.

Dock fick jag tipset utanför forumet att vid läggning av kort-orders bara dra saldot som vanligt sedan köra en ”återläggningsfunktion” som makulerar reservationer varje timme eller liknande exempelvis.

Vet inte vilket som har minst risk för fuckups, tänker mig att detta är en typisk sån grej som kan leda till mer problem än det löser om man gör fel

[Lastbryggan]

Vi skapar en temporär order så fort en kund lämnar vår kassa för att exempelvis flytta sig till betalfönstret hos 3 part. Denna temporära order reserverar varorna i kundvagnen och minskar varulagret.

Vid ex. en kortbetalning skapas den skarpa ordern först när callbacken från Dibs kommer tillbaka till oss. Kommer det ingen callback så släpps den temporära ordern och varorna ligger kvar i kundvagnen så att kunden kan välja ett annat betalningsalternativ.

Vi har dessutom fler fördelar med detta system då det temporära ordernumret blir samma som klockslaget då kunden lämnar vårt system (0926173315, just nu). Samtidigt som kunden lämnar vår kassa skickas ett kontrollmejl till oss med all info om ordern. Detta är bra att ha till hands de (få) gånger kunden fått igenom ett köp men inte callbacken funkade och den skarpa ordern inte registrerats.

Om callbacken inte funkar så triggar det även vårt system att mejla kunden om att nått har gått snett och när kunden då hör av sig så kan vi med hjälp av det temporära ordernumret lokalisera och skapa en order manuellt.

[Prix]

När det gäller kortbetalningar så har vi att när man lämnar vår sida så räknas lagret ner. Skulle sedan kunden hoppa av kortbetalningen på grund av misslyckat köp så makuleras ordern autmatiskt och lagret räknas upp direkt. Slutför kunden inte betalningen direkt så kan den återgå och betala och då är varan reserverad i cirka 1h, sedan släpps den och ordern makuleras och att återgå och betala ska inte vara möjligt (har inte hänt än i alla fall). Betalar kunden så kommer detta att loggas som betalt efter ett par minuter och under hela denna tiden fungerar det precis som tidsramen för 1h (ordern ligger där som inväntar betalning, när det sedan blir betald så aktiveras den för att packas).

Hoppas jag inte krångla till det för mycket och det var tips på sådana lösningar du efterfråga.

[Joel]

Ja det låter smart att aldrig egentligen reservera något utan bara kolla mot aktiva kundvagnen som gått vidare i kassan, och då dra av dessa mot saldot som visas i kassan för nästa kund.

Ett tredje alternativ kanske kan vara (beroende på hur integrationen med din betalleverantör ser ut) att helt enkelt kontrollera så saldot fortfarande finns när transaktionen sker hos din kund.

[Pelmered]

@Prix 69734 wrote:

När det gäller kortbetalningar så har vi att när man lämnar vår sida så räknas lagret ner. Skulle sedan kunden hoppa av kortbetalningen på grund av misslyckat köp så makuleras ordern autmatiskt och lagret räknas upp direkt. Slutför kunden inte betalningen direkt så kan den återgå och betala och då är varan reserverad i cirka 1h, sedan släpps den och ordern makuleras och att återgå och betala ska inte vara möjligt (har inte hänt än i alla fall). Betalar kunden så kommer detta att loggas som betalt efter ett par minuter och under hela denna tiden fungerar det precis som tidsramen för 1h (ordern ligger där som inväntar betalning, när det sedan blir betald så aktiveras den för att packas).

Hoppas jag inte krångla till det för mycket och det var tips på sådana lösningar du efterfråga.

Det här tycker jag låter som den bästa lösningen om inte ska krångla till det mer än nödvändigt.

[TimJ]

Ett alternativ är att ha två olika typer av reservationer. Varukorgsreservationer och orderreservationer. Lite förenklat och tekniskt följer. Förutsätter att man har en unik identifierare av kundvagnar och att flödet är varukorg -> order -> betalning -> utleverans.

0. Två olika tabeller:

stock
upc, qty
123123, 2

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

---

1. Vi lägger något i varukorgen
Reservationen läggs till.

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id
123123, 1, 1383080023, ’cart’, 9999, NULL

---

2. Varukorgen blir en order
Reservationen uppgraderas.

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id
123123, 1, NULL, ’preorder’, 9999, 1

ELLER

2. Varukorgen utgår
Tas bort via exempelvis cronjob och villkoret för expiry bör vara med i stock-queries.

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

---

3. Ordern utlevereras
Stock-tabellen uppdateras. Reservationer kopplade till ordern tas bort.

stock
upc, qty
123123, 1

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

ELLER

3. Ordern makuleras innan utleverans.
Tar bort relevanta reservationer.

stock
upc, qty
123123, 2

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

---

Ovan i text.
När man lägger något i varukorgen så skjuter man helt enkelt in en reservation i reservation-tabellen. När varukorgen sedan blir en order (även innan betalning) så ”uppgraderas” reservationen till en order-reservation. Vid eventuell makulering av ordern på grund av exempelvis utebliven betalning tar man helt enkelt bort de order-reservationerna som hör till den ordern (slipper göra en inleverans). Cart reservationerna tas bort med jämna intervall när expiry-time är uppnådd.

Vid utleverans av ordern uppdateras stock-tabellen och reservationerna tillhörande ordern tas bort. Nackdelen är att man lär summera mellan två tabeller och de blir ofta en separat query bara för att få ut ett saldo, vilket iof ofta inte är ett problem då man ofta inte vill joina en transaktions-heavy tabell med en mer statisk pga cache-lösningar osv.

På det här sättet skiljer man även ut vad som faktiskt finns på det fysiska lagret, vad som är på väg att utleveras och vad som ligger ”på gång”. Smidigt om man inte har separat affärsystem med lagerhantering (ex VB).

Nackdelen är att har man ett väldigt litet lager och inte support för backorders så kan hela den reserverbara stocken tas upp av kunder som bara nöjeslägger saker i varukorgen.

[bell]

Beroende på hur kritiskt detta är så finns det en viktig sak som jag tror ni missar. Att på ett eller annat sätt reservera en vara i lagret och låta den reservationen ligga medan köpet genomförs är bra. Risken att detta missbrukas höjs naturligtvis ju längre tid reservationen är giltig och därför är korta reservationstider att föredra. Inte så mycket som en timme, men nånstans 10 – 15 minuter.

Problemet som jag tror ni missar uppstår när en reservation läggs och betalningen tar längre tid än vad reservationen är giltig. Att höja reservationstiden minskar denna risk, men ökar å andra sidan risken för missbruk.

Det en behöver göra är att i callback från PSP kontrollera reservationen och om den har gått ut a) reservera på nytt, om möjligt b) om det inte är möjligt (slutsålt / fullt) neka transaktionen från callback så pengarna går tillbaka och köpet avbryts (efter att det genomförts så att säga).

Det är inte så många PSP som har stöd för att neka transaktioner när de har gått igenom (en reverse från callback) men några har det, exempelvis Paynova som SJ kör med.

En vattentät lösning är alltså reservation med låga reservationstider + kontroll av reservation i callback. Om det är en vara som är svår att beställa mer av eller där det säljs i hundratal per timme vid peak så behöver en gå hela vägen med reverse i callback.

Alternativet att köra reservationstiden lika lång som sessiontiden hos PSP är en enklare väg men kan fallera ifall sessionstiden ändras (förmodligen inte något som PSP kommunicerar ut) eller fördröjningar eller fel hos PSP eller inlösare sker. En enklare väg men fler felkällor.

[Författare]

Inlägg