WEIMI / CHECKOUT SCOPE
Approved in part.
Account for the whole basket.
The requested amount, authorized amount and remaining balance need separate records.
Introduction
A connected vending quotation includes a payment feature called partial authorization. A buyer may read that as a way to rescue an otherwise declined purchase. The operational question comes immediately afterward: if the card approves less than the basket total, what happens to the difference and when may the system treat the sale as funded?
Stripe’s public partial authorization guide describes approval for part of a requested amount when the available balance cannot cover it all. The customer can then use another payment method for the remainder. That is a conditional payment flow, not evidence that the original basket has already been paid in full.
The same guide restricts the documented feature to online card payments. This boundary matters in vending procurement. A page describing an online feature does not establish support on an unattended card reader, a particular terminal or any WEIMI machine. Use the source to frame questions for an explicitly proposed online integration and obtain separate evidence for the actual checkout.
Quick Answer
Require the proposal to show the requested amount, the authorized amount and the rule for the unpaid remainder. Then ask which record permits merchandise release or marks the agreed sale complete.
Stripe lists several possible responses to a partial authorization: create a separate PaymentIntent for another payment method, cancel the entire PaymentIntent, or capture only up to the partially authorized amount. The integrator must choose and explain the flow it actually offers. A feature name does not select that commercial behavior.
For a physical reader proposal, first resolve whether the cited documentation applies at all. The source reviewed here is for online card payments. Do not accept it as proof of card-present functionality or unattended deployment approval.
Comparison Table
| Outcome or decision | Amount evidence | Procurement question |
|---|---|---|
| Full authorization | Approved amount covers requested amount | What further capture and fulfillment steps apply? |
| Partial authorization | Approved amount is less than requested | How is the unpaid difference handled? |
| Second payment method offered | A separate attempt may cover the remainder | What proves the combined sale is funded? |
| Transaction canceled | The partial attempt is not continued | What does the customer see and what remains to reconcile? |
| Capture limited to approved amount | Collection does not exceed partial approval | What merchandise or revised sale does that payment cover? |
Who Should Buy This
This review is for operators comparing a connected checkout service, distributors assembling equipment and payment packages, and procurement teams evaluating a supplier’s claim about insufficient-balance handling. It is especially useful when an online checkout is explicitly included in the project.
Start by naming the customer journey. Is it an online purchase linked to equipment, a payment page, or a transaction performed on a physical reader? Ask the payment provider to identify the relevant product and eligibility. These are different integration scopes even if each ultimately relates to merchandise in a machine.
Include the party responsible for customer communication and exception handling. A partially funded basket can require a second interaction or a cancellation decision. Someone must own that experience and reconcile the records; it should not be left as an assumed capability of the cabinet.
How We Evaluate Smart Vending Machines
Our equipment shortlist uses three genuine current public WEIMI listings. It is based on public information, without independent testing or a ranking of payment performance. A screen, AI vision label or cabinet arrangement does not prove partial authorization support.
For the payment feature, we use Stripe’s partial authorization guide as a provider-specific example. Its restrictions, account enablement conditions and issuer/card dependencies prevent a universal support claim. The buyer must obtain confirmation for the offered account and checkout, rather than extrapolating from a documentation example.
We evaluate the clarity of the proposed flow: can the buyer distinguish the requested amount, the partial approval, any additional payment and the sale’s final business state? The suggested acceptance evidence below is a procurement framework. No live payment, integration test or machine trial was performed for this article.
Key Buying Factors
Check the eligibility before discussing the user experience
The reviewed Stripe guide states that partial authorizations are for online card payments and describes pricing/enablement and issuer/card conditions. Ask the provider to confirm that the feature is available for the proposed account and payment path. Do not translate a general card brand reference into guaranteed support for every card.
If the quotation instead concerns an unattended reader, request documentation for that exact payment product. Keep an unproven feature unresolved until the responsible provider supplies evidence. The machine’s ability to accept cards is a separate fact from a particular authorization option.
Preserve the requested and approved values separately
Stripe’s guide identifies fields for the originally requested amount, the authorized amount and the partial authorization status. An operator report that keeps only a generic “approved” label may hide a difference relevant to the basket. Ask which safe references and amounts the offered system preserves.
The acceptance case should show that a smaller approval is recognized as partial. A correct approval response is not an error merely because it is below the request; it is an outcome that requires the agreed next step.
Decide the remainder policy before deployment
Ask whether the proposed service requests another payment, cancels the attempt or continues with collection limited to the approved amount. The source presents these as different choices. The supplier should not promise that a second method is available unless that customer flow is implemented and included in the offer.
Where a sale is revised, define the revised merchandise and total explicitly. A partial payment by itself does not tell the machine which items to remove, whether a basket is reduced, or whether a new price is accepted. Those are application and commercial decisions requiring their own records.
Keep authorization, capture and merchandise release distinct
The source shows a manual-capture example and explains capture up to the authorized amount. It also states that overcapture cannot be used to collect more than the authorized amount when the transaction has been partially authorized. Do not build a procurement assumption that the missing balance can simply be captured later from that same partial approval.
Ask which final condition the application uses before marking the sale complete or permitting its agreed equipment action. A buyer needs that business rule even if the payment provider handles the technical API work. Authorization is one state in the flow, not a substitute for the entire flow.
Describe the customer’s next action clearly
Stripe asks users of the feature to communicate how the transaction will proceed and its potential impact. Request a demonstration of the proposed message and available next step. A customer should be able to understand whether another payment is requested, the sale is changing or the attempt is being canceled.
For an unattended operation, ask the integrator how the flow behaves if the customer leaves during the second step. Do not invent a timeout duration or automatic recovery policy. Obtain the actual supported behavior and name the support owner.
Reconcile the whole sale, not just one payment attempt
If the design uses a second payment attempt, ask how both records relate to the same basket. The proposed report should let an authorized reviewer distinguish a fully funded sale from a partial attempt with an unresolved remainder. It should also explain what happens when the second attempt fails.
Use approved test records and provider-supported references. No real card details are needed in a procurement evidence pack. Require the team to show the final record for each agreed branch rather than sending a live charge merely to make a demonstration look realistic.
Best Smart Vending Machines
The following public listings are a hardware buying shortlist. Select the shopping and merchandise format, then obtain separate payment-flow confirmation. None of the product references establishes the Stripe feature reviewed here.
Touchscreen snack and drink vending machine
The listing describes a snack-and-drink machine with a 21.5-inch touchscreen. Consider it when on-screen product selection fits the project. Ask how any separately offered checkout would present a remaining-balance decision and what application record would correspond to the selected merchandise.
Review the public touchscreen listing. A touchscreen does not establish split tender, partial authorization or the payment provider’s eligibility.
Single-Door AI Vision Smart Fridge for Packaged Drinks
The current page identifies an AI vision fridge for packaged drinks. Its legacy juice URL is not a specification for preparing juice. Evaluate that format against the intended assortment and shopping journey before reviewing any online checkout proposal associated with it.
Review the current fridge listing. AI vision does not prove a supported partial-payment flow or determine what happens to a basket that is not fully funded.
Two Cabinets, More Choice | Snack & Drink Vending Station
The public listing identifies a two-cabinet snack-and-drink station. Consider the format when it fits the site and product range. Ask whether the offered payment proposal treats selections as one sale or another explicitly documented arrangement.
Review the public two-cabinet listing. Two cabinets do not establish a combined basket, a shared merchant account or support for collecting a remainder.
Feature Comparison
| Public format | Question for the proposed checkout | Capability requiring separate proof |
|---|---|---|
| Touchscreen snack/drink machine | How does the customer see and resolve the remainder? | Partial approval and second-payment flow |
| Single-door packaged-drink AI fridge | Which final basket is associated with the payment result? | Funding rule before the agreed sale action |
| Two-cabinet station | How are selections and payment attempts grouped? | Combined sale and reconciliation design |
Cost & ROI Analysis
Assess partial authorization as a workflow with eligibility, implementation and support costs. Ask for a specific quotation for the offered account and checkout. The public product listings do not establish feature fees, payment charges or integration effort.
Hypothetical amount example only: assume an online basket requests USD 18, the issuer authorizes USD 11, and the application’s policy is to ask for another payment method. The unpaid remainder is USD 7. These invented values illustrate the accounting distinction; they are not a WEIMI transaction, price or measured customer outcome.
| Illustrative record | Amount | Meaning |
|---|---|---|
| Original basket request | USD 18 | Intended sale total before any revision |
| Partial authorization | USD 11 | Approved amount, not proof of capture |
| Unpaid difference | USD 18 − USD 11 = USD 7 | Requires the agreed remainder or cancellation decision |
If a second attempt is authorized for USD 7, the two approvals total USD 18 in this simplified example. That arithmetic still does not prove both payments were captured or that merchandise was released correctly. Each final state requires its own evidence.
No ROI, recovery rate or revenue uplift is predicted. Compare actual support workload and quoted costs after the provider confirms the flow. Do not multiply a hypothetical saved sale by an invented frequency to create a payback claim.
Best Choice by Scenario
The proposal is for a physical card reader: ask for the exact provider documentation applicable to that reader and deployment. The online-only feature page reviewed here is insufficient evidence.
An online checkout supports a second method: require a clear remaining-balance step and a sale record linking all attempts. Review the branch in which the second method is declined or abandoned.
The application cancels partial attempts: ask what the customer sees and how the canceled attempt is reconciled. Do not describe that flow as successful full-basket payment.
The offer captures only the partial amount: resolve what the smaller collection buys and how any revised sale is agreed. Keep the merchandise decision distinct from the payment amount.
The buyer wants to capture the original full amount afterward: do not assume overcapture solves the shortfall. The reviewed source prohibits overcapture on a partially authorized transaction; the actual remainder flow must be documented.
Applications
At quotation stage, ask the provider to attach its eligibility confirmation and remainder policy to the payment scope. Identify whether the project uses an online flow and which party supports the customer interaction.
At acceptance, request provider-approved cases for full approval, partial approval, a declined remainder and customer abandonment where those branches are offered. Record the final payment and sale states without treating a response label as the whole result.
At operational handover, preserve the reconciliation method and escalation route. Support should be able to find the original request, partial approval and any second attempt using safe references. The article does not perform transactions or access a merchant account.
FAQ
Does partial authorization mean the full basket is paid?
No. It can approve less than requested. The remainder and final collection state must be resolved under the offered flow.
Does the reviewed Stripe page prove support on an unattended reader?
No. It states that the feature is for online card payments. Request evidence for the exact physical payment product if that is the proposal.
What can happen to the unpaid remainder?
The source describes a separate PaymentIntent for another method, cancellation of the attempt, or capture limited to the authorized amount. Confirm the implemented choice.
Can overcapture simply collect the missing amount?
The reviewed source says overcapture is not available to exceed the authorized amount on a partially authorized transaction.
Are all cards guaranteed to support the feature?
No. The source describes eligibility, issuer and card-type conditions. Obtain confirmation for the actual provider account and checkout.
Which WEIMI product has been tested for this feature?
None in this article. The three real public listings are an equipment shortlist; payment capabilities require separate confirmation.
Final Recommendation
Evaluate partial authorization by what the proposed checkout does after approving less than the requested amount. Resolve eligibility first, then document the remainder policy, customer step and final sale condition.
A useful acceptance record follows the whole basket across its payment attempts. Keep hardware selection and payment-service confirmation connected through the order, while preserving the evidence boundaries of each.
CTA
Send WEIMI your merchandise, destination, preferred machine format and proposed payment journey. Request an equipment quotation that identifies confirmed hardware and separates any online checkout or payment-provider work requiring its own acceptance.
Source: Stripe — Partial authorization, accessed October 20, 2026 in Asia/Shanghai. The source’s online-payment restrictions and provider-specific conditions apply. Three linked public WEIMI pages support equipment identity only. No independent tests, live payment results, legal conclusions or SEO outcomes are claimed.
