Refund
Policy.

Our Refund Principle

MICROBA aims to handle refund and cancellation requests fairly, consistently, and according to the actual state of the transaction.

Canonical principle:

A refund reverses an eligible commercial transaction and, where necessary, reconciles the programme effects created by that transaction.

A refund is not complete merely because a request has been submitted.

The relevant Order, payment, fulfilment, Product, HIVE, SA, and other affected system records may need to be reviewed and reconciled.

Important: the MICROBA Moment™ is non-refundable

A MICROBA Moment™ purchase is final and non-refundable once payment succeeds.

The MICROBA Moment™ is not a physical good. It is a calculated Moment committed from the personal, place, date and environmental context you supply. On successful payment, MICROBA Product commits that Moment as an immutable record and issues the Moment of Truth Certificate from it. The thing purchased has, at that point, been created and delivered.

Because the committed Moment and its Certificate cannot be withdrawn, revoked or recreated, no refund, cancellation, partial refund or return is available for a MICROBA Moment™ Order after successful payment. This applies equally to Guest and member purchases.

The sections below describe MICROBA's general refund process. They apply to transactions that are eligible for refund under this Policy. They do not create a refund entitlement for a MICROBA Moment™.

Nothing in this Policy limits rights that cannot lawfully be excluded under applicable Indonesian consumer law.

Scope

This Policy may apply to:

• physical Products;
• eligible personalised Products;
• Orders;
• payment errors;
• duplicate payments;
• cancelled Orders;
• damaged or defective Products;
• incorrect Products;
• Products not received where responsibility lies with MICROBA or its fulfilment chain;
• eligible digital or service transactions where expressly stated; and
• related HIVE, SA, or other programme effects arising from a refunded transaction.

Different Products may have different return or refund conditions where those conditions are clearly disclosed before purchase and comply with applicable law.

Refunds Are Based on the Order

Refund eligibility is determined from the authoritative Commerce Order and related records.

Relevant information may include:

Order ID
Product
Product version
Quantity
Price paid
Payment status
Payment method
Order status
Fulfilment status
Delivery status
Refund history
Relevant Product terms
Related programme effects

Current Profile, Product, or pricing changes do not rewrite the historical Order.

Order Created Does Not Mean Paid

MICROBA distinguishes between:

Order Created
Payment Pending
Payment Confirmed
Order Processing
Order Completed

If payment was never successfully confirmed, a monetary refund may not be required because MICROBA may never have received the money.

The appropriate action may instead be to cancel or expire the unpaid Order.

Cancellation Before Payment

Where an Order has been created but payment has not been completed, the Order may be cancelled or allowed to expire according to the applicable Commerce rules.

No refund is normally due where no payment was collected.

Any temporary programme provision created before authoritative payment confirmation should be cancelled or reconciled according to the applicable system rules.

Cancellation After Payment but Before Fulfilment

If payment has been confirmed but fulfilment has not begun, you may request cancellation.

Where cancellation is operationally possible and no Product-specific restriction or mandatory legal rule provides otherwise, MICROBA may approve a full refund of the eligible amount paid.

Any associated programme effects may be reversed or cancelled.

Cancellation After Fulfilment Begins

Once preparation, personalization, manufacturing, fulfilment, dispatch, activation, or another irreversible process has begun, cancellation may be restricted.

Eligibility depends on:

• the Product;
• whether it is personalised;
• whether it is perishable;
• fulfilment stage;
• condition of the Product;
• reason for the request;
• applicable Product terms; and
• mandatory consumer law.

MICROBA will not use this section to avoid rights that consumers are legally entitled to exercise.

Personalised Products

Some MICROBA Products may be created, configured, prepared, or generated specifically for an individual.

Where legally permitted, change-of-mind cancellation may be limited once personalized production or fulfilment has begun.

This does not remove rights relating to Products that are:

• defective;
• unsafe;
• materially different from what was ordered;
• incorrectly supplied; or
• otherwise subject to mandatory consumer remedies.

Perishable, Consumable, or Hygiene-Sensitive Products

For safety and integrity reasons, some Products may not be returnable after opening, use, contamination, improper storage, or expiry of an applicable return period.

This may include Products that are:

• perishable;
• consumable;
• fermented;
• food-related;
• hygiene-sensitive; or
• otherwise unsuitable for resale after opening.

However, a non-returnable classification does not remove applicable rights relating to defective, unsafe, damaged, or incorrectly supplied Products.

Change of Mind

Unless a Product page or applicable law provides otherwise, MICROBA does not automatically guarantee a refund solely because a customer:

• changes their mind;
• no longer wants the Product;
• ordered the wrong quantity;
• entered incorrect information;
• dislikes a natural variation that is within the Product specification; or
• expected a result that was never guaranteed.

MICROBA may nevertheless approve a discretionary refund or cancellation where appropriate.

A discretionary approval on one occasion does not create a permanent entitlement for future transactions.

Damaged Products

If a Product arrives materially damaged, contact MICROBA within a reasonable period after delivery.

We may request information reasonably necessary to assess the issue, such as:

• Order ID;
• description of the damage;
• photographs;
• packaging condition;
• delivery information; and
• other relevant evidence.

Depending on the circumstances and applicable law, the remedy may include:

Replacement
Partial refund
Full refund
Other appropriate remedy

Defective or Unsafe Products

If you believe a Product is defective or unsafe, stop using it where continued use could reasonably create risk and contact MICROBA.

MICROBA may investigate:

• batch or Product information;
• storage and handling;
• reported condition;
• fulfilment history;
• Product specification; and
• other relevant circumstances.

Nothing in this Policy limits mandatory rights concerning unsafe or legally defective Products.

Incorrect Product or Quantity

If MICROBA supplies a materially incorrect Product or quantity, contact us with the Order details.

Where verified, MICROBA may provide an appropriate remedy such as:

• replacement;
• correction;
• collection/return arrangement;
• partial refund; or
• full refund.

Product Not Received

If an Order is marked fulfilled but you did not receive it, contact MICROBA.

We may review:

• delivery status;
• carrier records;
• recipient details;
• delivery address;
• proof of delivery;
• failed-delivery attempts; and
• other relevant information.

Where non-delivery is attributable to MICROBA or its fulfilment chain and the customer is legally entitled to a remedy, MICROBA may arrange replacement or refund.

If delivery failed because materially incorrect information was supplied by the customer, additional delivery costs or restrictions may apply where permitted by law.

Natural Product Variation

Natural, agricultural, biological, or fermented Products may reasonably vary in characteristics such as:

• colour;
• aroma;
• texture;
• appearance; or
• other naturally variable qualities.

Reasonable natural variation within Product specification is not automatically a defect.

This does not apply where the Product is unsafe, spoiled, materially non-conforming, or otherwise legally defective.

Product Expectations and Results

MICROBA does not generally provide refunds merely because a Product did not produce a subjective, biological, health, lifestyle, business, or other result that was never expressly guaranteed.

Individual outcomes may vary.

This section is subject to the MICROBA Disclaimer and mandatory consumer law.

Duplicate Payments

If the same payment obligation is accidentally paid more than once and the duplicate payment is verified, MICROBA will normally refund or otherwise reconcile the excess amount.

A duplicate payment investigation may require payment-provider confirmation.

Incorrect Charge

If you believe the amount charged differs materially from the amount you validly confirmed, contact MICROBA.

We may compare:

Committed Order amount
Payment-provider record
Discounts
Taxes
Delivery charges
Refunds
Adjustments

Where an incorrect excess charge is verified, MICROBA will provide the appropriate correction or refund.

Failed or Pending Payments

A payment marked:

Pending
Failed
Expired
Cancelled

is not necessarily refundable because the funds may not have been finally received by MICROBA.

If funds appear to have left your account while Commerce still shows a failed or pending payment, MICROBA may need to reconcile the payment-provider record before determining the appropriate action.

Cash on Delivery

Selecting Cash on Delivery (“COD”) does not mean the Order has been paid.

The conceptual lifecycle may include:

Awaiting Collection
Collected
Verified
Paid

A cash refund can only relate to an amount actually collected and verified, subject to the applicable refund conditions.

Refusal of a COD delivery may be treated as cancellation or failed fulfilment according to the applicable Product and Commerce rules.

Repeated abusive COD activity may result in restrictions where permitted by law.

Payment Provider Refunds

Approved refunds may be returned through:

• the original payment method;
• an approved alternative method where necessary; or
• another lawful method agreed or required in the circumstances.

The time required for funds to appear after MICROBA initiates a refund may depend on the bank, payment provider, card network, or other financial intermediary.

MICROBA does not control third-party processing time after a refund has been correctly submitted to the relevant provider.

Refund Amount

A refund may be:

Full
Partial

depending on the circumstances.

The refundable amount may consider:

• amount actually paid;
• quantity affected;
• Product condition;
• fulfilled portion;
• approved delivery charges;
• discounts;
• prior refunds;
• mandatory consumer rights; and
• other legitimate transaction adjustments.

MICROBA should clearly record the refund amount and reason.

Delivery and Shipping Charges

Whether delivery or shipping charges are refundable depends on:

• reason for the refund;
• whether delivery occurred;
• whether MICROBA supplied an incorrect or defective Product;
• applicable Product terms; and
• mandatory law.

Where the refund results from MICROBA’s material fulfilment error, applicable delivery costs may also be refundable where required.

Return Shipping

Where a physical return is required, MICROBA will provide or communicate the applicable return process.

Responsibility for return shipping costs depends on:

• reason for return;
• Product condition;
• fault;
• applicable Product terms; and
• mandatory consumer law.

Do not return a Product to an arbitrary address without following the instructed return process.

Proof of Purchase

MICROBA may require reasonable proof that the transaction belongs to the person requesting the refund.

The MICROBA Order ID is the preferred reference.

We may also use:

• MID;
• payment reference;
• recipient information;
• email;
• transaction reference; or
• other reasonable verification information.

Refund Request Process

A refund request should normally include:

Order ID
Affected Product
Reason
Relevant details
Requested resolution
Supporting evidence where applicable

Review

Submitting a request does not automatically approve a refund.

MICROBA may review:

Order
Payment
Product
Fulfilment
Delivery
Evidence
Prior adjustments
Programme effects
Applicable law

before making a decision.

Refund Status

A refund workflow may use statuses such as:

Requested
Under Review
Approved
Rejected
Processing
Completed
Reversed / Corrected

The exact implementation may vary.

A status should not be represented as completed until the authoritative Commerce/payment process supports that state.

Approved Refund

When a refund is approved, MICROBA may:

1. record the approval;
2. determine the refundable amount;
3. initiate the refund through the applicable method;
4. reconcile the Order;
5. notify affected MICROBA programme capabilities; and
6. preserve an audit record.

Refund Completion

A refund may involve two distinct milestones:

Refund Initiated

and:

Refund Completed / Provider Confirmed

Where third-party confirmation is available, MICROBA should use authoritative provider information rather than assuming completion immediately after initiation.

Refund Rejection

If a request is rejected, MICROBA should provide an understandable reason where reasonably possible and legally appropriate.

A rejection may be reviewed through the applicable support or dispute process.

HIVE Effect of Refunds

If an eligible sale created HIVE commission, qualification, or another affiliate effect, a refund may require that effect to be adjusted.

Conceptually:

Eligible Sale
-> HIVE Effect

Sale Refunded
-> HIVE Reversal / Adjustment

An affiliate is not entitled to retain a commission that depended on a transaction that was validly reversed, unless the applicable HIVE rules expressly provide otherwise.

Pending HIVE Commission

If a refund occurs before a related commission becomes final:

Pending Commission
-> Cancel / Recalculate

according to HIVE rules.

The system should avoid paying commission on invalid or refunded commercial activity.

Paid HIVE Commission

If commission has already been paid before the underlying sale is refunded, HIVE may create a governed adjustment or recovery according to the applicable programme rules.

Historical commission transactions should not simply be deleted.

SA Effect of Refunds

A refunded transaction may affect:

SA Provision
SA Entitlement
New SA Generation
Recycled SA Assignment
Other SA-related programme effects

The exact action depends on how far the SA lifecycle progressed.

Refund Before SA Entitlement

If an eligible sale created only backend SA provision and the sale is refunded before a whole-SA entitlement is finalized:

Provision
-> Reduce / Cancel

according to the applicable SA rules.

No issued SA needs to be removed if no SA was actually assigned.

Refund After SA Entitlement

If a refunded sale already resulted in an SA entitlement or assignment, the SA system must reconcile the effect according to the applicable programme rules.

Possible governed outcomes may include:

Entitlement Reversal
SA Return
Treasury Adjustment
Compensating Transaction
Other Approved Reconciliation

The system must not silently delete SA transaction history.

New and Recycled SA

Refund reconciliation must preserve the distinction between:

New SA

and:

Recycled SA

A recycled SA must not be counted as newly generated merely because a refund or reversal occurs.

Its serial identity and lineage should remain traceable.

SA Already Transferred or Used

If an SA arising from a refunded transaction has already been transferred, gifted, donated, spent, or redeemed, automatic reversal may not be operationally or legally appropriate.

The case may require governed reconciliation according to SA programme rules.

MICROBA should not invent or duplicate SA merely to simplify a refund.

Treasury Reconciliation

Where refund processing affects Treasury SA inventory, the Treasury state and related programme records should be reconciled through the authoritative SA process.

Treasury balances should not be manually edited simply to make a refund appear balanced.

Sponsorship Reconciliation

Where the SA programme uses an internal Sponsorship counter or ledger linked to Treasury movement, any required refund-related adjustment should be processed according to the canonical SA/Treasury rules.

The customer-facing refund amount is determined by Commerce and the payment transaction.

The Sponsorship ledger is an internal programme mechanism and should not be confused with the customer’s cash refund.

Refund Does Not Create New SA

A refund must not cause accidental double counting.

Canonical principle:

Refund reconciliation corrects the consequences of a transaction; it does not create duplicate programme value.

Other Programme Benefits

A refunded transaction may also affect:

• discounts;
• rewards;
• eligibility;
• qualification;
• promotional benefits;
• certificates;
• recognition; or
• other conditional programme outcomes.

Each owning capability is responsible for determining the correct reversal or adjustment under its rules.

Partial Refunds

A partial refund may require proportional or rule-based programme reconciliation.

For example:

Original eligible sale
Rp1,000,000

Refund
Rp200,000

Remaining eligible sale
Rp800,000

HIVE, SA provision, and other programme effects should be recalculated from the authoritative remaining eligible transaction value according to their rules.

Full Refunds

A full refund generally removes the refunded sale from eligible commercial value, subject to applicable programme rules and any amounts that are lawfully non-refundable.

Affected downstream programme effects should then be reconciled accordingly.

Discounts and Promotional Purchases

Refunds for discounted or promotional purchases are generally based on the amount actually paid and the applicable Product/promotion terms, not an undiscounted hypothetical price.

Where a promotion depended on purchasing multiple Products, a partial return may require recalculation of the remaining eligible promotion where permitted by law.

Gift Purchases

Where a Product was purchased for another person, refund rights generally belong to the purchaser unless applicable law or the Product terms provide otherwise.

The recipient may still be able to report damage, defect, or fulfilment issues.

Fraud and Abuse

MICROBA may investigate refund requests involving suspected:

• fraud;
• duplicate claims;
• falsified evidence;
• payment manipulation;
• intentional chargeback abuse;
• HIVE manipulation;
• SA manipulation;
• false non-delivery claims; or
• other abuse.

Legitimate consumer claims will not be rejected merely because MICROBA operates fraud-prevention controls.

Chargebacks and Payment Disputes

If you initiate a bank, card, or payment-provider dispute, MICROBA may provide relevant transaction evidence to the provider as permitted by law.

A chargeback or payment dispute may cause the Order and related programme effects to enter a pending or reconciliation state.

Do not use a chargeback as a substitute for fraud.

Where practical, contacting MICROBA first may allow an issue to be resolved more quickly.

Refund Audit Trail

Refund-related records should preserve:

Request
Reason
Evidence
Decision
Approver where applicable
Refund amount
Payment-provider reference
Commerce adjustment
HIVE effect
SA effect
Timestamps
Corrections / reversals

Historical records should be corrected through governed events rather than deletion.

Manual Refunds

Manual refund processing should be restricted to authorized operators.

Where a manual process is required, it should record:

• reason;
• amount;
• Order;
• operator;
• approval where required;
• payment reference; and
• audit history.

Manual processing must not bypass HIVE or SA reconciliation where those systems were affected by the original transaction.

No Manual Balance Editing

Operators should not resolve a refund by directly overwriting:

Commerce totals
HIVE commission balances
SA holdings
Treasury SA
Sponsorship records

The appropriate transaction, reversal, or compensating process must be used.

Refund Notifications

MICROBA may notify you when a refund is:

Received
Approved
Rejected
Initiated
Completed

Notifications are informational.

The authoritative Commerce/payment record determines actual refund status.

Refund Processing Time

MICROBA should process approved refunds within a reasonable period.

The final time for funds to appear may vary by:

• payment method;
• bank;
• card network;
• payment provider;
• weekends;
• public holidays;
• currency processing; and
• other external factors.

Currency

Refunds are normally calculated using the currency and amount applicable to the original transaction.

Where currency conversion occurs through a bank or payment provider, exchange-rate differences or third-party fees may arise outside MICROBA’s control, subject to applicable law.

Account Closure

Closing a MICROBA account does not automatically cancel valid refund rights.

MICROBA may retain and use transaction information reasonably necessary to process:

• pending refunds;
• disputes;
• chargebacks;
• HIVE reconciliation;
• SA reconciliation;
• audit; and
• legal obligations.

Suspension or Termination

A suspended or terminated account may still have legitimate refund rights under applicable law and contract.

Suspension does not by itself permit MICROBA to ignore a valid refund claim.

Fraudulent or abusive activity may nevertheless affect the investigation and remedies available.

Mandatory Consumer Rights

Nothing in this Policy is intended to exclude, restrict, or modify rights that cannot lawfully be excluded, restricted, or modified.

Where applicable consumer law provides a stronger remedy than this Policy, the mandatory legal protection prevails.

Changes to This Refund Policy

MICROBA may update this Policy as Products, Commerce, payment providers, fulfilment, programmes, or legal requirements evolve.

The effective date should be updated when a revised version is published.

A later Policy should not be used to unlawfully remove rights that already arose under an earlier transaction.

Contact

Refund requests and questions may be sent to hello@microba.co.

Official website: https://microba.co/.

Do not send passwords, full payment-card credentials, or unnecessary sensitive information in a refund request.