WEIMI / PAYMENT DATA BRIEF
Price 10.
Amount 1000.
Which units?
A currency code and a field definition connect the numbers.
Introduction
A vending catalogue shows a price of 10. A payment record shows an amount of 1000. That difference is not enough to prove a hundredfold charge. The provider may represent the amount in minor currency units while the screen displays major units. The buyer needs the currency, field definition and conversion rule before comparing the numbers.
The reverse error matters too: a team that multiplies every price by 100 can misrepresent a currency whose documented charge amount is already expressed without decimal subdivision. A working payment terminal is therefore only part of acceptance. The integration and reports must agree on what each amount means.
This guide addresses representation across the catalogue-to-payment boundary. It does not calculate foreign-exchange rates, choose a tax policy or decide where a worksheet rounds totals. No live payment was made and no WEIMI integration was independently tested.
Quick Answer
Never move a bare number across a payment handoff. Pair the amount with a currency code, its unit convention and the provider operation. Ask the implementer to show how the displayed price becomes the provider amount and how the report converts it back for human review.
Stripe’s public currency documentation gives two clear examples: an amount value of 1000 charges 10 USD, while 10 charges 10 JPY. It also documents special cases. These facts show why a universal multiply-by-100 rule is unsuitable. They do not establish that Stripe is installed on a WEIMI machine or that a proposed export uses the same representation.
Approve a configuration-specific mapping with test examples. Include a two-decimal currency, a zero-decimal currency if relevant to the project, and any documented exception for the actual market. Do not add unsupported currencies merely because they appear in a generic provider list.
Comparison Table
| View or field | Example meaning | What acceptance must establish |
|---|---|---|
| Customer price | 10 USD displayed as a human-readable price. | Correct currency and intended final purchase total. |
| Provider amount | 1000 in Stripe’s documented USD example means 10 USD. | Field units for the specific provider and operation. |
| Zero-decimal example | 10 in Stripe’s documented JPY example means 10 JPY. | No automatic assumption that every currency is multiplied by 100. |
| Operator export | May contain raw integers or formatted money. | Schema, currency field and whether conversion has already occurred. |
| Bank settlement report | May describe a different currency or net amount. | Do not compare it as if it were the same original charge field. |
Examples are documentation explanations, not actual vending prices or charges. The same characters can describe different amounts when the currency or unit definition changes.
Who Should Buy This
This brief is for distributors commissioning a payment integration, operators importing catalogue prices, and finance teams reviewing a new transaction export. It is particularly useful when one team maintains product prices while another supplies the terminal or payment software. A successful screen demonstration does not settle the data contract between them.
Bring the implementer and payment provider into the review. Procurement should be able to ask what 1000 means without needing to reverse-engineer source code. The answer should name the field, currency and applicable rule in plain language, with traceable acceptance examples.
A single-country rollout also needs this check. Multiple currencies make assumptions more visible, but one wrong conversion can affect one currency just as easily. Conversely, a software catalogue supporting several currency labels does not prove the payment account can process them.
How We Evaluate Smart Vending Machines
We use public WEIMI product listings to compare physical shopping formats and official Stripe documentation to explain a real provider’s amount conventions. This is a procurement shortlist, not an independent payment benchmark. The following checks are proposed acceptance work, not reported test results.
Trace the same intended amount through each boundary
Ask the supplier to start from an approved catalogue price and currency. Have the implementer show the payment request representation using an approved test environment and redacted evidence. Then inspect the corresponding human-readable result and export field. The acceptance record should explain each representation rather than simply noting that the numbers differ.
Keep selection or recognition evidence beside the payment evidence. A fridge can identify the correct products while the amount handoff is still wrong; a correctly formatted payment request can also relate to the wrong basket. Both tasks need evidence. Neither should be inferred from the other.
Make negative cases explicit
Agree the supported behavior for a missing currency, an unsupported currency or a value that cannot be represented under the provider’s rules. Ask the team to demonstrate its approved validation approach. This does not assert that any listed machine supplies those validations as standard. Do not run malformed live payments as a casual procurement test.
Key Buying Factors
Amount and currency travel together
Use an explicit currency field in the handoff specification. A symbol such as a dollar sign can be ambiguous across markets, and an integer alone cannot identify its value. Confirm whether the provider expects an ISO currency code and the exact format it accepts. Stripe’s documentation uses three-letter currency codes and describes its request conventions; another interface must be checked on its own terms.
Conversion happens at a named boundary
Document which component changes a human price into the provider’s representation. A catalogue service, payment adapter and reporting tool should not each apply a conversion independently. Ask for evidence that a formatted major-unit value is not multiplied again during export and that a raw minor-unit integer is not shown to an operator as a full monetary price.
Special cases remain visible
The cited documentation includes currency-specific rules, including differences connected to charges and payouts. Therefore “zero-decimal” alone is not a complete implementation specification. Ask the actual provider to identify the relevant rule for the actual operation and currency. This article intentionally does not publish a universal conversion table for every currency.
Display precision is not the data contract
A screen showing two decimal places does not establish that the underlying provider field is a decimal number. A spreadsheet formatting a value as money also does not prove that conversion occurred. Review the field definition, not only a screenshot. Keep locale-specific separators and rounding policy as separate decisions with their own acceptance evidence.
Configuration changes trigger a review
A new destination, payment provider, export version or price-import tool can introduce a different unit convention. Include the mapping in change review. A previous acceptance test for USD is useful evidence for that configuration; it does not automatically validate a later JPY deployment or a different provider.
Best Smart Vending Machines
The three products below are a shortlist based on public WEIMI listings, not an independently tested ranking. Their listed shopping functions are relevant to the purchase; payment provider, country support, field representation and currency handling require project confirmation.
WEIMI WM22 Touchscreen Snacks & Drinks Machine
WM22 lists a 21.5-inch touchscreen, multiple-item purchasing and optional adjustable dispensing slots. It is a candidate for an approved packaged assortment where customers select products before delivery. Test the physical packages against the chosen channels.
Amount review: follow a selected basket from displayed unit prices to the intended total and the configured payment request. Ask which field units the terminal integration uses. Multi-item purchasing does not prove a particular currency conversion, tax calculation or export schema.
Review the WM22 listingWEIMI Single-Door AI Vision Smart Fridge
The AI fridge page describes direct selection of packaged drinks and compatible snacks with automated checkout. Its card-payment configuration leaves the terminal, local service and transaction workflow for project confirmation. Recognition must be tested using actual packaging and shelf arrangements.
Amount review: inspect the final basket calculation separately from its payment encoding. If an authorization-and-capture design is proposed, ask for the units and currency of each relevant amount. The listing does not establish that design, a fixed reserve or Stripe integration.
Review the AI fridge listingWEIMI Dual-Cabinet Snack & Drink Vending Station
The dual station shows main and secondary retail sections, a portrait interface and a payment area. Confirm the exact dispensing, payment and purchase scope for both sections. A common visual station does not prove one shared basket or one payment account.
Amount review: map each supported purchase route to its payment reference and currency. If a combined purchase is proposed, require its real configuration demonstration. An extra cabinet does not itself change the provider’s amount unit or establish multi-currency processing.
Review the dual-cabinet listingFeature Comparison
| Question | WM22 | AI fridge | Dual station |
|---|---|---|---|
| Where is the intended basket established? | Review the configured touchscreen selection flow. | Review recognized products and final basket evidence. | Confirm supported purchase scope across sections. |
| Which mapping must be shown? | Displayed total to provider request. | Basket amount to payment lifecycle fields. | Each purchase route to amount and currency. |
| What is not established publicly? | Universal amount conversion or export schema. | Installed Stripe provider or a fixed reserve. | Shared basket, account or multi-currency acceptance. |
Choose the equipment for product handling and site fit. Approve its payment amount contract as a separate part of that configured solution.
Cost & ROI Analysis
The purpose of the amount-unit review is to prevent unsupported financial interpretation. It does not establish a return on investment or a measured defect rate. Budget provider coordination, integration review and relevant regression checks alongside payment hardware and service fees.
| Illustrative item | Hypothetical input | Arithmetic |
|---|---|---|
| Mapping review labour | 40 minutes at US$30 per hour. | 40 ÷ 60 × 30 = US$20. |
| Provider amount example | Stripe documentation: amount 1000 with USD. | Human amount is US$10 under that example. |
| Zero-decimal comparison | Stripe documentation: amount 10 with JPY. | Human amount is JPY10 under that example. |
The US$20 labour allowance is invented planning arithmetic. It is not a WEIMI quotation or measured saving. The two currency rows explain documented representation; they are not equivalent prices, an exchange-rate comparison or recommended vending prices.
An error in a representation should not be multiplied by assumed transaction volumes and presented as a proven loss. First establish what the installed system actually does, which records are affected and the provider’s resolution procedure. Keep actual investigation findings separate from a hypothetical financial scenario.
Best Choice by Scenario
A selected snack-and-drink basket: consider WM22 and demonstrate a configured total before dispensing. Record the relationship between displayed money and provider amount without assuming the interface uses decimal values.
An open-door assortment: consider the AI fridge when direct selection fits the products. Verify recognition and price calculation, then review the amount representation at the payment handoff. These are related but distinct acceptance steps.
A broader two-section offer: evaluate the dual station only after confirming transaction boundaries. Document amount and currency for each actual supported route. If multiple currencies or combined baskets are requested, identify them as proposed scope until confirmed.
Applications
A price import handed to an integrator
Provide a field specification with currency and unit definitions alongside approved examples. Do not rely on a column headed “amount” with no explanation. Ask whether the import already contains provider units or human prices, and preserve that decision in the accepted file version.
A report delivered to finance
Label raw amount fields and formatted monetary fields clearly. Finance should not need to guess whether 1000 is a price or an integer representation. If the export supplies several stages of a payment, identify the meaning of each field rather than converting every number as if it were a sale.
A destination-market change
Have the provider reconfirm account availability, currency support and operation-specific rules. A country name in an equipment shipping proposal does not prove payment acceptance there. These are proposed review scenarios, not claims about installed customer systems.
FAQ
Does amount 1000 always mean a price of 1000?
No. In Stripe’s documented USD example, 1000 means US$10. Determine the currency and field units before interpreting any number. Another field or provider can use a different convention.
Should every displayed price be multiplied by 100?
No. Stripe documents JPY as a zero-decimal example and also lists special currency cases. Ask for the rule applicable to the exact currency and operation rather than applying one factor universally.
Is this an exchange-rate calculation?
No. Representation converts between units within a defined currency. Foreign-exchange conversion changes between currencies and needs a separate rate, timing and fee specification.
Does a currency symbol on the screen prove payment support?
No. Confirm the actual account, provider, payment method and country support. A display label cannot establish an approved payment integration.
Does WEIMI supply Stripe for these models?
No such integration is established here. Stripe documentation supplies a verifiable example of amount conventions. Confirm the proposed terminal and provider for the actual order.
What acceptance evidence should the buyer request?
Request the field mapping, currency, unit convention, named conversion boundary and approved test examples. Include export interpretation and the owner responsible for maintaining the mapping after changes.
Final Recommendation
Make amount representation explicit in the payment deliverables. Require an amount-plus-currency mapping, a named conversion boundary, provider-specific exception handling and a human-readable export definition. Approve the relevant examples before treating a payment demonstration as complete.
Select WM22, the AI fridge or the dual station for the actual shopping and product-handling task. Then verify the configured payment handoff. A bare integer, a currency symbol or a money-formatted spreadsheet cell is insufficient evidence of what a customer will be charged.
Sources and limits
Reviewed 15 October 2026: Stripe supported currencies and amount formatting and the three linked WEIMI listings. Stripe is a provider-specific example only. No live transaction, integration code inspection, independent equipment test, search-volume dataset or measured ROI was used.
CTA
Request a configuration-specific vending proposal. Send your destination, product assortment, quantity and payment requirements. Ask WEIMI to identify the proposed payment provider and include currency support, amount-field mapping, acceptance evidence and report definitions in the project review.
