Scope of This Payment Policy
This policy applies to payments and contributions made to niinii through any payment channel or payment service provider made available on the relevant niinii checkout page. niinii is not limited to a single gateway. The provider and payment methods actually shown at checkout are the authoritative options available for that transaction.
Important: not every provider or payment method listed below is enabled at the same time. Availability may depend on merchant approval, provider account configuration, country, currency, transaction type, device, card or bank eligibility, and the rules of the payment provider.
Payment Channels niinii May Offer
- Payment gateway checkout, including card, supported wallet, bank redirect, local payment method or other provider-supported methods.
- DuitNow QR or other supported QR payment methods.
- Domestic bank transfer.
- International bank transfer / SWIFT transfer.
- Receiving-account or multi-currency collection services where supported.
Provider-Specific Reference
The following sections explain how niinii may use each provider. A provider is only considered available to a payer when it is actually presented on the relevant checkout or payment instruction page.
1. Stripe
Stripe may be used for hosted checkout and other supported online payment flows. Depending on the niinii Stripe account configuration, payer country, currency and payment-method eligibility, Stripe may present cards, supported wallets, FPX or other Stripe-supported payment methods. niinii confirms successful Stripe transactions from provider-side payment status and webhook events rather than relying only on the browser return page.
For FPX, Stripe documentation states that FPX is a Malaysia payment method presented in MYR, supports refunds and partial refunds, and is not a recurring payment method. Payment-method availability remains subject to Stripe account eligibility and configuration.
Official references: Stripe Checkout documentation · Stripe FPX reference · Stripe Refunds API
2. Airwallex
Airwallex may be used where niinii enables Airwallex Payments or related collection functionality. Airwallex supports global and local payment methods, but the exact method shown to a payer depends on factors such as business location, shopper location, presentment currency, payment-method activation and the integration used. niinii should rely on Airwallex payment status and webhooks for final server-side confirmation where Airwallex is used.
Official references: Airwallex Payment Methods · Airwallex Payments Webhooks
3. WorldFirst
WorldFirst is treated primarily as international collection, receiving-account, foreign-exchange and payout infrastructure rather than automatically as a consumer card checkout gateway. Where niinii uses WorldFirst, payment instructions may involve a local or cross-border bank transfer into a WorldFirst Receiving Account or other WorldFirst-supported collection arrangement. Supported currencies, countries and payment networks depend on the WorldFirst product and account configuration.
Official references: WorldFirst Receiving Accounts · WorldFirst Fund Collection Methods · WorldFirst API Overview
4. Ezypay
Ezypay may be used for supported payment collection flows. Ezypay payment methods are country-specific. Its current developer documentation lists Malaysia support for Visa, Mastercard, Apple Pay and Google Pay, subject to merchant onboarding, product eligibility and activation. niinii will only present Ezypay where the relevant Ezypay service has been enabled for the transaction.
Official reference: Ezypay Supported Payment Methods
5. CHIP
Where CHIP is offered, niinii may redirect the payer to CHIP or use another CHIP-supported integration. CHIP publicly documents support for payment methods including FPX, DuitNow QR, cards and supported e-wallets, with additional methods depending on the merchant setup. niinii should use server-side CHIP event or webhook confirmation where integrated and should not treat a browser return alone as final proof of settlement.
Official references: CHIP Collect Payment Methods · CHIP Webhook Guidance
6. PayPal
PayPal may be added or used where it is expressly shown at checkout. PayPal Checkout can present PayPal and, depending on region, eligibility and integration, supported card or alternative payment methods. niinii will rely on PayPal server-side payment status and applicable webhook events for final payment confirmation if PayPal is enabled.
Official references: PayPal Checkout · PayPal Webhooks
7. Billplz
Billplz may be used for Malaysian Ringgit payment collection where enabled. Billplz documentation states that its API accepts MYR and does not perform currency conversion. Billplz uses a server-side callback for reliable payment completion updates and may also redirect the payer back to the merchant site for user experience. Where Billplz is enabled, niinii will use the provider callback / verified transaction status as the payment source of truth.
Official references: Billplz API Documentation · Billplz Webhooks & Callbacks
8. toyyibPay
toyyibPay may be used where expressly enabled. Its API documentation supports bill payment channels including FPX, credit card and, where activated for the account, DuitNow QR. toyyibPay provides return and callback mechanisms and transaction-status APIs. niinii will validate the provider callback / transaction status before treating the transaction as completed.
Official reference: toyyibPay API Reference
9. senangPay
senangPay may be used where expressly enabled. senangPay provides payment-page and API-based integration options, including a return URL and callback URL for transaction notification. The exact payment channels available depend on the merchant account, enabled senangPay services and current provider configuration. niinii will not assume a payment channel is available unless it is activated and presented to the payer.
Official references: senangPay API Catalogue · senangPay Manual Integration API
Other or Future Payment Providers
niinii may add, replace or remove payment providers as the platform evolves. If a provider is not listed above but is displayed on a niinii checkout page, the transaction will also be subject to that provider's applicable terms, payment-method rules, security requirements, refund rules and service availability. niinii will not intentionally present a provider as active unless the corresponding integration and merchant account are enabled.
Payment Status & Source of Truth
A browser success page, redirect page, screenshot, email notification or payment-attempt message by itself is not final proof that niinii has received cleared funds. For integrated gateways, niinii uses the provider-side transaction record, signed callback, webhook, API status or equivalent server-to-server confirmation as the payment source of truth. For direct bank transfers, niinii may rely on verified bank transaction records or other approved reconciliation evidence.
Card, Wallet & Banking Security
niinii does not intentionally store full card numbers, CVV/CVC security codes, online-banking passwords or raw wallet credentials on its own application database. Sensitive payment credentials should be collected and processed by the relevant payment service provider or regulated payment channel used for the transaction.
Currency, Foreign Exchange & Provider Fees
The currency displayed before payment is the transaction presentment currency. A payment provider, card issuer, bank, wallet operator or intermediary bank may apply processing fees, cross-border fees, foreign-exchange conversion, intermediary-bank charges or other charges according to its own rules. Where niinii displays an estimated fee or estimated net amount before payment, that figure is informational. The final provider transaction, settlement record or balance transaction is the authoritative record for actual provider fees, exchange rate and net settlement received by niinii.
For international transfers, the payer is responsible for confirming the sending currency, beneficiary details and any bank/intermediary charges before authorising the transfer.
Refunds
Refund eligibility is governed by the niinii Refund Policy, the relevant service terms and the rules of the original payment provider. A refund may be full or partial where supported. A refund is not considered completed merely because niinii has recorded a refund request; the final refund state is determined by the provider or banking channel used for the original transaction.
Where a provider supports server-side refund events, callbacks or API status, niinii may use those events as the source of truth for refund completion. Processing time before funds appear back in the payer's account may depend on the payment method, provider, bank or card issuer.
Disputes, Chargebacks & Reversals
A dispute or chargeback is different from a voluntary refund. Where a payer raises a payment dispute through a card issuer, bank, wallet or payment provider, the transaction may be investigated, temporarily reversed or otherwise adjusted under that provider's dispute process. niinii may update the internal payment record based on provider-side dispute events and final outcomes.
Provider Terms Also Apply
By selecting a third-party payment method, the payer may also be subject to the terms, privacy notices and payment rules of that provider, card issuer, bank or wallet operator. niinii does not control provider outages, bank approval decisions, authentication requirements, provider settlement schedules or provider-specific payment-method eligibility.
Questions or Payment Issues
For payment questions, refunds or reconciliation issues, contact customer@niinii.com and provide the niinii reference number, payment date, amount, currency, payment method and any provider transaction reference available. Do not send full card numbers, CVV/CVC codes, online-banking passwords or one-time passwords to niinii.
Policy Record
Version: 2026.10.17
Last updated: 17 October 2026
Provider capabilities can change; the provider documentation and merchant-account configuration current at the time of each transaction remain authoritative for provider-specific availability.