POS integrācijas prasības

Fooodo ir viesiem paredzēts pasūtīšanas un maksājumu slānis, kas darbojas virs esošās POS sistēmas. Viesi pasūta un maksā pie galda, izmantojot QR; pasūtījumi tiek ierakstīti POS sistēmā caur servera puses savienotāju un nonāk tajā identiskā veidā kā pasūtījumi, kas ievadīti terminālī. POS sistēma netiek aizstāta: tā paliek kā galvenā uzskaites sistēma ēdienkartes pārvaldībai un patiesības avots virtuves darbībai un pārskatiem.

Šis dokuments nosaka, ko Fooodo integrācija prasa no POS sistēmas — operācijas, kuras POS API jāatklāj, entītiju līmeņa datu prasības, savienojamības un veiktspējas prasības, kā arī kļūmju semantiku —, kam seko novērtēšanas kontrolsaraksts un ceļš uz ražošanu. Paredzētais lasītājs ir POS pārdevēja inženieru komanda, kas novērtē iespējamību un nepieciešamo darbu.

Integrācijas virziens: Fooodo izsauc POS API. Savienotāju implementē un ekspluatē Fooodo; jūsu puse nodrošina, dokumentē un atbalsta API virsmu, kas ir sasniedzama no Fooodo mākoņa. Fooodo programmatūra netiek instalēta vai mitināta POS pusē. Atsauces savienotājs, kas implementē šo līgumu, darbojas ražošanā vairāku atrašanās vietu ķēdē; jauni savienotāji tiek apjomoti katram klientam atsevišķi, kad ķēde paraksta līgumu.

Kā integrācija ir veidota

• Fooodo ir viesiem paredzēts pasūtīšanas un maksājumu slānis; POS turpina vadīt virtuvi — tās pašas printera maršrutēšanas, tās pašas KDS, tie paši pārskati.
• Līgums ir šāds: pasūtījums, kas izveidots caur Fooodo, nonāk POS sistēmā neatšķirams no pasūtījuma, kas ierakstīts terminālī. Virtuves personālam nav jāzina, ka Fooodo pastāv.
• Fooodo ir izsaucošā puse. Lasīšana tiek aptaujāta pēc grafika (ēdienkarte, pasūtījuma stāvoklis); rakstīšana notiek brīdī, kad notiek notikums (pasūtījums izveidots, pasūtījums apmaksāts). Fooodo nepatērē tīmekļa āķus vai notikumu push no POS — jums nav nepieciešams tos veidot.
• Jūsu puse nodrošina, dokumentē un atbalsta API — Fooodo veido un pārvalda visu pārējo.
• Atsauces dati ir tikai lasāmi pāri robežai: Fooodo nekad nemaina POS ēdienkarti, cenas, modifikatorus vai citus pamatdatus.

Ko jūsu POS sistēmai jāatklāj

Savienotāja līgums aptver četras jomas — atrašanās vietas, ēdienkartes, pasūtījumus un maksājumus. Konkrēti, kā operācijas — šeit nosauktas vispārīgi; jūsu API tām būs savi nosaukumi:

Šī ir arī pilnīgā rakstīšanas virsma — pāri šai robežai nav atcelšanas, anulēšanas vai atmaksas rakstīšanas. Anulēšana notiek POS terminālī kā parasti (Fooodo to uztver caur notiekošā pasūtījuma atsvaidzināšanu), un atmaksas apstrāde atrodas ārpus savienotāja — tā nekad neskar jūsu API.

Fooodo izmanto divus pasūtīšanas plūsmas veidus — Pay-First un Pay-Later daudzraundus ēšana uz vietas, kur raundi tiek pievienoti atvērtam POS pasūtījumam un apmaksāti beigās (skatīt fooodo.com/docs/order-flows). Iepriekš minētās operācijas aptver abus; iespēja pievienot vienumu atvērtam pasūtījumam ir tas, uz ko Pay-Later visvairāk paļaujas.

Līgums ir definēts kā operācijas, nevis kā vadu formāts — savienotājs tiek veidots katram klientam pret jau esošo saskarni. Jūsu API transporta veids un formāts tiek pārskatīts apjomošanas laikā; iespējamībai svarīgi ir tas, ka iepriekš minētās operācijas ir atklātas kaut kādā veidā.

Ja jūsu POS nevar tieši atklāt kādu no nepieciešamajām operācijām, tas automātiski nav strupceļš — tas ir pirmais jautājums, ko apjomošanas zvans risina.

Kā dati izskatās

Entītiju līmeņa prasības, lai jūsu komanda varētu tās kartēt pret savu datu modeli. (Lauku līmeņa shēmas atrodas integrācijas repozitorijā, ko partneri saņem onboarding laikā.)

• Ēdienkarte — kategorijas, kas satur produktus; produktiem ir cenas, nodokļu karodziņi, varianti (piem., izmēri) un modifikatoru grupas (sastāvdaļu pievienošana / noņemšana / apmaiņa, katrai ar savu cenu). POS paliek patiesības avots: Fooodo lasa šo struktūru, nekad to neraksta.
• Pasūtījums — atsauce uz konkrētu galdu konkrētā atrašanās vietā; rindas vienumi ar izvēlēto variantu, modifikatoriem un daudzumiem; kopsummas. Pasūtījumiem var pievienot vienumus, kamēr tie ir atvērti (Pay-Later plūsma pievieno raundus atvērtam POS pasūtījumam), un atlaides vai lojalitātes efekti tiek atspoguļoti pasūtījumā, ko saņem POS.
• Maksājums — "apmaksāts" atzīme, kas tiek pielietota esošam pasūtījumam. Dzeramnaudas var tikt novirzītas uz noteiktu rindu POS sistēmā. Kartes vai maka dati nekur neparādās šajā plūsmā.
• Statuss — atrašanās vieta tiešsaistē/bezsaistē; pieejamība katram vienumam ("izpārdots" karodziņi); katra pasūtījuma stāvoklis, ieskaitot "bloķēts — atvērts terminālī". Pasūtījumi, kas ielādēti no POS, var saturēt piešķirto viesmīļa identifikatoru, ko Fooodo izmanto personāla atribūcijai pārskatos.

Savienojamības prasības

Šī ir daļa, uz kuru lielākā daļa novērtējumu balstās.

• Katras atrašanās vietas POS API jābūt sasniedzamai no Fooodo mākoņa caur internetu, izmantojot HTTPS, ar stabilu katrai atrašanās vietai paredzētu URL. Fooodo konfigurācijā katram restorānam ir API galapunkts un atrašanās vietas identifikators — šim galapunktam jāatbild, kad Fooodo izsauc.
• Lokālā POS: vietai nepieciešams uzticams platjoslas savienojums, un POS API jābūt atklātai Fooodo drošā veidā — caur jūsu pārdevēja mākoņa vārteju, VPN tuneli vai nocietinātu reverso starpniekserveri vietā. Mehānisms tiek saskaņots apjomošanas laikā; "POS ir sasniedzama tikai no lokālā tīkla" ir visbiežāk sastopamā nepilnība.
• Mākoņa POS: servera-uz-serveri (S2S) savienojums starp Fooodo mākoņa un jūsu mākoņa API, ar katrai atrašanās vietai paredzētiem akreditācijas datiem un identifikatoriem.
• Savienojuma kvalitāte ir svarīga, ne tikai tā esamība. Pasūtījuma izveide un apmaksas atzīmēšana atrodas viesa norēķināšanās kritiskajā ceļā, un tiešsaistes/bezsaistes pārbaude darbojas katru minūti, lai Fooodo varētu pārslēgt atrašanās vietu uz tikai lasāmu režīmu brīdī, kad POS kļūst nesasniedzama. Savienojums, kas pārtrūkst uz dažām minūtēm, tiek apstrādāts graciozi; savienojums, kas visu dienu svārstās, pasliktina viesa pieredzi šajā atrašanās vietā neatkarīgi no tā, cik laba ir integrācija.

Veiktspējas robežas

Atsauces izvietojums izmanto šādus ritmus katrai atrašanās vietai visu diennakti apkalpošanas laikā:

Jūsu API jāspēj uzturēt šo aptaujāšanu visām savienotajām atrašanās vietām vienlaicīgi, un diviem kritiskā ceļa rakstīšanas darbiem — pasūtījuma izveidei un apmaksas atzīmēšanai — jāpabeidzas sekunžu laikā. Rakstīšanas darbiem, kas neizdodas, tiek mēģināts atkārtoti pēc eksponenciāla atkāpšanās grafika, tāpēc īslaicīga noraidīšana ir atgūstama; hroniski lēns galapunkts nav.

Kļūmju semantika, uz kuru paļaujas Fooodo

Integrācija ir veidota, lai tolerētu īslaicīgu POS nepieejamību, un tā paļaujas uz to, ka POS atgriež atšķiramas kļūdas:

• "Pasūtījums ir bloķēts / atvērts terminālī" jābūt atšķiramam no nopietnas kļūmes. Atsauces savienotājs atpazīst specifiskus bloķēšanas kļūdu kodus un reaģē, atkārtoti mēģinot ar īsu atkāpšanos (aptuveni pieci mēģinājumi ~2,5 minūšu laikā), nevis atgriežot kļūdu. Apmaksas atzīmēšanas noraidījumi tiek atkārtoti pēc lēnāka grafika (~17 minūtes), jo apmaksāts pasūtījums tiek saskaņots, nevis bloķē apkalpošanu.
• Nesasniedzama POS automātiski pārslēdz atrašanās vietu uz tikai lasāmu režīmu. Kešotā ēdienkarte joprojām ielādējas viesiem, jauni pasūtījumi tiek bloķēti norēķināšanās brīdī ar skaidru ziņojumu, un rindā esošie atjauninājumi tiek apstrādāti, kad POS atgriežas — bez operatora iejaukšanās.
• Atkārtotiem rakstīšanas darbiem jābūt drošiem. Fooodo atkārto neveiksmīgus pasūtījumu iesniegšanas mēģinājumus; apjomošanas laikā mēs kopīgi pārbaudām, ka atkārtots mēģinājums pēc taimauta nevar dubulti izveidot pasūtījumu jūsu pusē.

Vairāku atrašanās vietu ķēdes

Fooodo ir veidots ķēdēm. Katram restorānam uzņēmumā ir savs POS galapunkts, atrašanās vietas identifikators un akreditācijas dati — dažādas atrašanās vietas var norādīt uz dažādiem POS gadījumiem — un, veidojot papildu savienotājus, uz dažādām POS sistēmām. Novērtējiet ķēdes vissliktāk savienotajai atrašanās vietai, nevis labākajai.

Drošība

• Viss savienotāja trafiks darbojas caur HTTPS/TLS ar katrai atrašanās vietai paredzētiem akreditācijas datiem. Akreditācijas datu mehānika (API atslēga, tokens, OAuth, mTLS) tiek saskaņota apjomošanas laikā.
• Kartes dati nekad nešķērso POS robežu. Maksājumi tiek veikti caur Fooodo atsevišķo maksājumu pakalpojumu (Mollie — karte, Apple Pay, Google Pay); jūsu POS saņem pasūtījumu un vēlāk "apmaksāts" atzīmi, nekad maksājuma instrumenta datus. Integrācija nepievieno nekādas kartes datu plūsmas jūsu POS sistēmai.
• Fooodo plašākā drošības nostāja — šifrēšana, apakšprocesori, GDPR — ir dokumentēta vietnē fooodo.com/security.

Vides un testēšana

• Tiek sagaidīts jūsu POS testa gadījums. Fooodo izstrādes vide darbojas pret jūsu testa vidi; ražošanas trafiks to nekad neskar.
• Mock režīms ļauj agrīnajai izstrādei darboties pret Fooodo ēdienkartes lietotni ar POS trafiku, kas ir imitēts no gala līdz galam — noderīgi pirms jebkādas savienojamības ir izveidota.
• Partneri saņem integrācijas repozitoriju — pilnu savienotāja līgumu ar versiju fiksāciju — onboarding laikā.

Novērtēšanas kontrolsaraksts

Jūsu darba apjoma novērtēšanai darbs jūsu pusē parasti koncentrējas četrās vietās: nepilnību novēršana attiecībā pret nepieciešamajām operācijām; API atklāšana katrai atrašanās vietai (skatīt Savienojamību); katrai atrašanās vietai paredzētu identifikatoru un akreditācijas datu izsniegšana; un testa vides izveidošana.

Ja uz šiem jautājumiem varat atbildēt ar "jā", integrācija visticamāk ir iespējama:

1. Vai jūsu POS atklāj API, kas aptver nepieciešamās operācijas — ēdienkartes lasīšanu, pasūtījuma izveidi, vienumu pievienošanu jau atvērtam pasūtījumam, apmaksas atzīmēšanu, atrašanās vietas statusu?
2. Vai šo API var padarīt sasniedzamu no interneta caur HTTPS katrai atrašanās vietai — pārdevēja mākonis, S2S, VPN vai drošs starpniekserveris?
3. Vai katrai atrašanās vietai ir stabils identifikators un akreditācijas dati?
4. Vai API atgriež atšķiramas kļūdas "pasūtījums bloķēts terminālī" salīdzinājumā ar nopietnām kļūmēm?
5. Vai tā var uzturēt aptaujāšanu katru minūti katrai atrašanās vietai un pabeigt pasūtījumu rakstīšanas darbus sekunžu laikā?
6. Vai ir testa vide, pret kuru var darboties Fooodo izstrādes vide?
7. Vai pasūtījumi, kas izveidoti caur API, uzvedas tieši tāpat kā termināļa pasūtījumi virtuvē (drukāšana, KDS, pārskati)?
8. Vai atkārtotu pasūtījuma izveidi pēc taimauta var padarīt drošu pret dubultu izveidi — ar idempotences atslēgu vai veidu, kā pārbaudīt, vai pasūtījums jau pastāv?

"Nē" vai "neesmu pārliecināts" uz kādu no šiem jautājumiem ir tieši tas, kam paredzēta apjomošanas saruna — vairākiem no tiem ir vairāk nekā viena iespējamā atbilde.

No novērtēšanas līdz dzīvam savienotājam

1. Novērtēšana — jūsu komanda pārskata šo rokasgrāmatu, aizpilda kontrolsarakstu un mēs salīdzinām piezīmes. Parasti to izraisa kopīgs restorāna klients.
2. Apjomošana — darba sesija, kurā jūsu API tiek kartēta pret savienotāja līgumu; nepilnībām tiek meklēti risinājumi. Fooodo apjomo un kotē sava savienotāja izveidi katram klientam atsevišķi, kad ķēde apņemas; darbs, kas nepieciešams jūsu pusē, tiek novērtēts tajā pašā sarunā kopā ar komerciālo vienošanos. Noderīgi sagatavot: jūsu API dokumentāciju, testa vides plānu, katrai atrašanās vietai paredzētus identifikatorus un tehnisku kontaktpersonu jūsu pusē.
3. Izveide un testēšana — izstrāde sākas mock režīmā, pēc tam pāriet uz jūsu testa vidi pret Fooodo izstrādes vidi.
4. Pilotprojekts un ieviešana — vispirms viena dzīva atrašanās vieta, pēc tam visa ķēde.

Lai sāktu: nosūtiet savus kontrolsaraksta atbildes un aptuvenu darba apjoma novērtējumu jūsu pusē uz partners@fooodo.com, vai izmantojiet izstrādātāja veidlapu vietnē fooodo.com/developers. Izveides līmeņa skats — integrācijas repozitorijs ar pilnu savienotāja līgumu — tiek nodots onboarding laikā.