Understanding payment status
Open the corresponding Foody workspace described below.
Refund or void a Verifone online payment
In Admin → Orders, open the order and its payment section. An owner or manager with payments.manage can use Refund or void payment for a single verified ILS Verifone online sale or confirmed capture. Table/session, mixed tenders, partial collections, external-terminal payments and catering deposits are not supported by this control. An uncaptured hold still uses the existing cancellation/release workflow.
Check Available to refund, then choose Refund payment. Keep Full remaining amount or choose Partial amount and enter the exact amount. Enter a reason of 3–300 characters, review the amount in the confirmation and submit once. Successful matched refunds already visible in Verifone history reduce the ceiling, including refunds made in Central; incomplete or unverified history blocks a new operation. The bounded history lookup covers transactions created within two years.
A captured ABS sale still AUTHORISED/AUTHORIZED or SETTLEMENT_REQUESTED is not settled: Admin shows Available to void and only Void entire payment, with no prior refund. Refund payment and Available to refund require an explicit settled state or verified partially-refunded history. Generic APPROVED/COMPLETED, contradictory states or missing evidence offer neither action. A state change before confirmation rejects the stale action; it never switches VOID to REFUND automatically. Request rejected by Verifone means no return of funds is confirmed, not necessarily an issuer decline. VOID is full only, never partial. Eligibility follows the provider state and merchant/acquirer rules, not midnight or a fixed 24-hour cutoff. Final acceptance is confirmed by Verifone.
Read Payment operations for the amount, reason, date, actor account and provider transaction ID. Confirmed by Verifone requires an independent transaction read with matching parent, amount, currency, reference and merchant. A partial refund leaves the payment marked paid; a full confirmed return marks its payment refunded. Neither changes food status, items, stock or fulfillment.
If the result is unknown or the browser loses the response, do not submit another refund or switch to VOID. Use Check with Verifone, which only verifies existing operations. A request with no recoverable provider ID stays blocked for support/Central verification, including after reload or an API restart. Never treat an HTTP success alone as refunded. Check the corresponding Invoice4U credit/cancellation document separately; this control does not confirm or create a fiscal credit document. FoodyPOS has a separate Transactions workflow for a server-verified original Checkout payment; these Admin instructions do not cover POS terminal refunds.
After a full return verified against matched Verifone history, the summary keeps the original amount, shows the full amount returned and zero remaining, and offers no further refund or VOID. A cleared capture balance after that return is not an uncaptured hold to release. Missing or inconsistent evidence still requires verification without resubmission.
Refund a POS-listed online payment to its original method
In POS Transactions, choose a confirmed Verifone Checkout payment and request a return only when the server verifies its original payment ID, merchant, provider status and available amount. The selected transaction must match the order's payment; a shared order is not enough to authorize a different charge. A settled payment may be refunded to the same card, while an eligible captured unsettled payment may be voided in full. Enter a reason and confirm once. If the result is unknown, use the existing-operation check rather than submitting again. This does not refund a Victa terminal card payment or turn a card payment into a cash return.
Keep the hosted payment form readable
When Foody enables a restaurant-branded Verifone hosted checkout, the payment page uses light surfaces and dark text, even if the restaurant website is dark. The published logo is kept and the brand/button accent is adapted when needed for readable contrast. This concerns online hosted payments, not POS terminals or native Apple Pay/Google Pay sheets. If an older page is unreadable, contact the Foody team to resynchronize its payment theme. The update applies to newly issued Checkout links, not the page already open. Check the current payment status before requesting another link; never repeat a debit because of a display problem.
Review the by-weight authorization ceiling
For online by-weight orders, open Settings → Payments & VAT with settings.edit. Set Weight hold buffer % from 0 to 100 and save; the default for new restaurants is 20. A failed save keeps the draft. Zero still authorizes the estimate. Only the weight-priced subtotal gets a margin: 100 weighted + 50 fixed at 20% authorizes 170; delivery has no extra margin. Checkout shows the estimate, temporary ceiling and Confirm and authorize, in the restaurant theme. A changed ceiling requires customer review and another confirmation before payment; unknown policy blocks authorization. Existing reviewed checkouts and holds keep their ceiling. Staff confirm measured weights before capture and progression; excess beyond the hold is flagged for a separate payment, never automatically charged. Cash/pay-later makes no hold promise. Requires a configured authorize/capture provider, with partial capture, release and expiry validated before production. This neither changes the catering deposit/balance policy nor enables new-card saving with a CST weighted hold.
Payment configuration
The payment provider is configured for each restaurant by the Foody team through the backoffice. Available payment methods depend on that configuration, the merchant contract and the order channel. Sumit and Verifone are integrated; availability must be confirmed for your installation. New PayPlus checkout is disabled.
Check an online payment
- Open the order in Orders.
- Check its payment status and recorded method.
- A return from a payment page is not by itself proof of payment. Foody verifies the payment with the provider before marking it paid.
- For online orders requiring payment, confirmation makes the order available to the POS workflow.
A failed or uncertain result
Do not assume that a timeout means no money was taken. Check the order and provider transaction before retrying a charge. Contact Foody support if they disagree or the outcome is unclear. Never include full card details, CVV or credentials in a support message.
Cash/manual recording, receipts, invoice issuance and refunds are separate operations. Their available controls depend on your setup and permissions. Do not record a card payment as successful solely because a customer shows a return page. Ask support for the procedure applicable to your provider before a refund or correction.
Save a card during the first payment (CST)
On the CST test setup validated with Verifone, sign in or create your Foody customer account, explicitly select Save card, then confirm the order. The hosted Verifone page collects the card, CVV and Israeli ID and charges the full order amount while creating the reusable token. There is no separate 1 ILS registration payment and no automatic monthly charge. Foody opens confirmation only after verifying the transaction. On later orders, choose the saved card and explicitly confirm the new amount; the configured No-CVV contract requires neither CVV nor Israeli ID. A delayed result requires checking status, never repeating the debit. Previously issued registration links keep their old recovery flow. Weighted holds remain outside this new registration flow. Production availability requires separate merchant approval.
Check an itemized Invoice4U invoice
When Invoice4U issuance and an invoice document type are enabled by the Foody team for the merchant, ordinary immediate Verifone order payments send the saved order lines: items and quantities, selected variants/options, combo base and included components, order discount and delivery fee. Frozen prices already include VAT; it is not added again. The line total must equal the payment amount or payment initiation is blocked. The same detail is sent for a later saved-card sale. Legacy orders without catalogue lines and catering/table/capture operations keep their existing document behavior. An approved payment is not proof that Invoice4U issued a fiscal document: check the document in Verifone Central/Invoice4U and customer delivery. Do not create another payment to obtain a missing invoice.
Stock reservations after late payment
Predefined item stocks now have a journal under Items & menus → Stock history and on each product. A rotating carte can prepare initial allowances per series and publish them without restoring already committed units. Previous remaining counts are not carried forward. Order changes and pre-production releases use the original frozen pool; a produced item remains consumed. Ingredient/preparation quantities and recipe costs remain separate. See Availability for initial imports, corrections and history filters.
Access the new controls
The entry sign-in invitation is now a published website order-journey preference. Order without an account remains available; this setting does not replace mandatory phone verification or payment/delivery validation. Google/Geoapify consumption and limits are separately available in Usage and quotas.
Sumit prepared orders
Compatible versions offer a Sumit-only Foody basket link and hosted card entry in Admin. The customer-link choice allows details to be completed by the recipient. Prepared pending baskets stay immutable; check the saved order before recovery. See the complete Sumit procedure. Publish this guidance with the matching API, Admin and guest Web rollout.
Prepared basket and restaurant presentation
A private Sumit prepared-order link enters the restaurant’s existing cart, then its checkout with the published colors, fonts and fields. The personal browser basket is retained; prepared items, prices and date stay fixed. Contact details and requested answers belong to this order, without loading an account or saved card. Custom answers bind when payment first opens. Delivery fees are recalculated and reviewed before payment. See the Sumit procedure.
Use cash with an optional card guarantee
In order details, the Card guarantee panel separates the reserved amount, validity and state from the money received. Record the full cash amount only after physically receiving it through the existing authorized collection flow; an open physical drawer still requires the same POS cash context. Recording cash prevents a concurrent card debit and requests release. A release awaiting confirmation does not undo received cash. Partial cash payments and relabelling the guaranteed payment as an external card/transfer are refused while the guarantee is active. If no cash was received, staff with payments.manage may choose Charge the guaranteed card and explicitly confirm the full debit. There is no automatic debit for an unpaid order. The sale becomes card-paid only after Stancer confirms capture. Do not use manual status corrections to simulate a guaranteed payment.
Acceptance and recovery: cash card guarantees.
Review independent confirmations
The summary distinguishes recorded collections and refunds, net received and the remaining balance. An unknown value is not zero; a refund does not automatically recreate debt. The summary authorizes no new charge and existing financial flows remain required. See recorded amounts.
Event orders and bank reservations
For saved-event edits, explicit production inclusion, private links, deposits and Sumit authorizations kept separate from received money, see Event / Catering.
Review the physical card destination
With the compatible POS/API, review the physical card destination before collection: see Mini/Portable selection and verified hardware setup. Existing order IDs, QR separation, kitchen progression and table-release settings remain independent. An unresolved terminal reservation blocks another collection; recover the original operation rather than creating a replacement sale.