“We accept local payments” is too broad to put beside a Malaysian power-bank cabinet. A physical bank card, an online banking redirect and a wallet QR code are different customer journeys. An operator needs a method matrix showing which route is available, which payment behaviour has been tested and what the customer must bring.
Define the reader service first
Stripe’s Malaysian Terminal guidance lists Visa and Mastercard, with MYR transactions and a Malaysian receiving account and reader Location. WisePad 3 appears in the supported reader table. Confirm the actual operator’s eligibility and local procurement route before ordering.
In CoreCharge’s matched WisePad 3 configuration, a native Android rental application and Terminal SDK run inside the cabinet. The reader connects through the agreed USB data and power arrangement. A customer can present a supported physical card without an external merchant phone hosting the transaction. Stripe handles payment into the operator’s own local account, while CoreCharge connects the order, dispensing, return and rent calculation.
Give each requested method its own row
| Requested route | What the team must prove | What may be advertised |
|---|---|---|
| Physical Visa or Mastercard | Actual local reader payment and the complete rental flow. | Only the verified card route and supported conditions. |
| Card presented through a mobile wallet | Supported wallet, card network and real-environment outcome. | Only the wallet presentations actually accepted. |
| Optional H5 card checkout | Customer phone access, configured page and order linkage. | The separately configured online route. |
| FPX online banking | Separate integration, account availability and rental design. | No acceptance claim until that scope is completed. |
| DuitNow or another local QR/wallet request | Named provider, supported account and explicit implementation evidence. | No inference from a card-reader connection. |
This matrix is a proposed acceptance document, not a list of methods already integrated into every CoreCharge cabinet. Mark each row as confirmed, under review or outside launch scope, with a named person and evidence reference.
Keep online banking distinct from card-present rental
Stripe describes FPX as a Malaysian online payment method using the customer’s online banking credentials and bank authorization flow. That is not the same interaction as presenting a card to WisePad 3. The payment confirmation, customer equipment and later adjustment process need their own design.
A provider’s public documentation can establish what that provider offers, but it does not establish that CoreCharge has implemented the route in your project. Do not copy an FPX, DuitNow or wallet logo onto the station because the operator has heard of it or sees it in another checkout.
Test the business rule as well as the payment name
For every enabled route, record the initial financial result, when a bank may be released and how the final rent is determined. If an eligible card route uses authorization and later capture, verify its conditions and timing. Do not describe an immediately captured amount as an uncaptured hold, or assume every method permits the same non-return collection.
Use the same rental reference when checking payment, release and return. An approved payment without a bank requires investigation; a bank returned without a recorded return event requires a different check. Keep the support procedure beside the matrix instead of promising a universal automatic refund.
Make the public sign narrower than the internal wish list
The venue sign should show only launch-ready routes. Explain MYR pricing, any authorization, return limits and the help contact. A guest whose phone is empty should immediately understand whether a supported physical card is enough; an optional phone-based route should not be the only explanation.
The Canadian payment-method guide demonstrates why an acceptance label cannot replace financial-flow checks, without implying Malaysian methods behave like Interac. Use the complete rental validation guide for the physical evidence.
Confirm reader suitability and the intended operating environment before opening. Review CoreCharge’s reader-equipped stations, or request a Malaysian payment-method scope review with the exact methods you want to offer.
References and project scope
Technical references checked on 17 October 2026. The operating procedures above are planning guidance; hardware, account access and payment settings are confirmed for each deployment.