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ā no galda, izmantojot QR; pasūtījumi tiek ierakstīti POS sistēmā, izmantojot servera puses savienotāju, un nonāk tieši tāpat kā pasūtījumi, kas ievadīti terminālī. POS sistēma netiek aizstāta: tā paliek kā galvenā uzskaites sistēma izvēlnei un patiesības avots virtuves darbībām un pārskatiem.

Šis dokuments nosaka, ko Fooodo integrācija prasa no POS sistēmas — operācijas, kuras POS API jāatklāj, datu prasības entītiju līmenī, 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 darba apjomu.

Integrācijas virziens: Fooodo izsauc POS API. Savienotāju īsteno un uztur 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 īsteno š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 pievienojas.

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, tas pats KDS, tie paši pārskati.
• Līgums ir šāds: pasūtījums, kas izveidots, izmantojot Fooodo, nonāk POS sistēmā neatšķirami 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 (izvēlne, 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 nevajag tos veidot.
• Jūsu puse nodrošina, dokumentē un atbalsta API — Fooodo veido un uztur visu pārējo.
• Atsauces dati ir tikai lasāmi pāri robežai: Fooodo nekad nemaina POS izvēlni, 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, izvēlnes, 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ā tas notiek šodien (Fooodo to uztver, atsvaidzinot pasūtījumu izpildes laikā), 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 daudzraundu ēšanu 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 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 atsevišķi pret jau esošo saskarni. Jūsu API transports 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

Prasības entītiju līmenī, 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ā.)

• Izvēlne — 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 preces, kamēr tie ir atvērti (Pay-Later plūsma pievieno raundus atvērtam POS pasūtījumam), un atlaižu 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ē; katras preces pieejamība ("izpārdots" karodziņi); katra pasūtījuma stāvoklis, ieskaitot "bloķēts — atvērts terminālī". Pasūtījumi, kas iegū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 internetā, izmantojot HTTPS, ar stabilu katrai atrašanās vietai paredzētu URL. Fooodo konfigurācija satur API galapunktu un atrašanās vietas identifikatoru katram restorānam — š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ā — izmantojot 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ākoni 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 rakstiem — pasūtījuma izveidei un apmaksas atzīmēšanai — jāpabeidzas sekunžu laikā. Raksti, kas neizdodas, tiek atkārtoti pēc eksponenciāla atkāpšanās grafika, tāpēc īslaicīgs noraidījums ir atgūstams; hroniski lēns galapunkts nav.

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

Integrācija ir veidota, lai tolerētu īslaicīgi nepieejamu POS, 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 konkrētus bloķēšanas kļūdu kodus un reaģē, atkārtojot 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 lēnākā grafikā (~15 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ā izvēlne 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 iztukšoti, kad POS atgriežas — bez operatora iejaukšanās.
• Atkārtotiem rakstiem jābūt drošiem. Fooodo atkārto neizdevušos pasūtījumu iesniegšanu; apjomošanas laikā mēs kopīgi pārbaudām, ka atkārtojums 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, izmantojot 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, izmantojot 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 kartes datu plūsmas jūsu POS sistēmai.
• Fooodo plašākā drošības pozīcija — š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.
• Maketēšanas režīms ļauj agrīnajai izstrādei darboties pret Fooodo izvēlnes lietotni ar POS trafiku, kas ir maketē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 piespraušanu — 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 — izvēlnes lasīšanu, pasūtījuma izveidi, preču 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, izmantojot 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 rakstus sekunžu laikā?
6. Vai ir testa vide, pret kuru var darboties Fooodo izstrādes vide?
7. Vai pasūtījumi, kas izveidoti, izmantojot 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 — idempotences atslēga vai veids, 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 dzīvotspējīga 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 kārtību. 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 maketēšanas 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 ķē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ā.