Refunds and refund recording

A refund returns purchase funds to a customer and records that outcome. InAppify refund recording does not automatically transfer funds for every payment method. Identify the method first: Bazaar behaves differently from bank payments and Myket.

Behavior by payment method

• Bank payments and other non-Bazaar paths, including Myket: the operation records a refund in InAppify without sending a fund-transfer request to a bank or Myket. Return funds through the appropriate provider or valid business process before recording the actual outcome.
• Cafe Bazaar: InAppify first submits a refund request to Bazaar using the purchase token. Only a successful response leads to internal refund recording. Valid app details and store API credentials are required.

For funds handled through InAppify's gateway, coordinate the return procedure with support before recording a refund. This record does not itself execute a bank transfer or pay funds from InAppify's account.

How Cafe Bazaar refunds work

Use Refund transaction in InAppify for a Bazaar purchase. InAppify submits the refund to Cafe Bazaar so the refund is performed on the store side. Only after Bazaar responds successfully does InAppify create its refund record and apply your choice to retain or revoke linked access. This differs from returning funds elsewhere and manually recording the result for non-Bazaar purchases.

If Bazaar rejects the request or purchase information is incomplete, the operation returns an error; do not assume success. After a communication error, check the store result and transaction history before retrying. Customer fund-return timing follows Bazaar's process; submitting a request does not guarantee an exact payout time.

Eligible transactions

A transaction must be successful, non-trial, have a positive amount, and not already be refunded. You also need the project's transaction refund permission. If the action is missing, check eligibility and collaborator permissions.

The current form records the entire transaction amount; it has no custom amount field and does not provide partial refunds.

Dashboard procedure

1. Select the project and find the purchase in Transactions or the customer's transaction history.
2. Confirm the customer, amount, currency, app, and payment method. For non-Bazaar purchases, confirm funds have actually been returned.
3. Choose Refund transaction from the row's actions menu.
4. Enter a clear refund reason, such as “Customer requested purchase cancellation”. This is required and limited to 1,000 characters.
5. Enter the refund reference if available. It is optional and limited to 150 characters. Distinguish the return reference from the original purchase reference.
6. Explicitly choose whether to revoke or retain the entitlement created by this transaction.
7. Review the details and select Confirm and record refund. After success, check the refunded badge and refund details.

Revoke or retain access

Revoke access: if an active entitlement linked to this payment exists, that record becomes inactive. A future expiration, or unlimited access, is capped at the revocation time. This does not remove every entitlement the customer owns; another purchase or grant may still provide access.

Retain access: the refund is recorded without revoking the linked entitlement. Choose this according to your business's refund policy.

If no active linked entitlement is found, refund recording may succeed without revoking access. Review the actual revocation result in transaction details rather than inferring it from the selected option.

History and limitations

• The successful purchase remains, with a separate refund record; its payment state is not changed to unsuccessful.
• Reason, amount, optional reference, recording time, and revocation outcome are retained. Transaction details display refund information.
• Resubmitting an already-refunded transaction does not create a second refund. Do not use resubmission to change the reason or revocation choice.
• The form provides no refund undo or recorded-refund edit action. Review carefully before confirming.
• Do not assume recording a refund automatically rewrites every past invoice or settlement. Review the relevant financial report and contact support about discrepancies.

Common errors

• Unsuccessful or non-positive transaction: it is not eligible. For uncertain results, start with payment inquiry.
• Refund in progress: wait for the earlier request and review history before trying again.
• Incomplete Bazaar refund details: check the app identifier, purchase token, and Bazaar API configuration.
• Bazaar refund failed: do not assume an internal success; investigate with the store and support.

After a network error, review transaction details and, for Bazaar, the store result before retrying. An error alone does not prove that no action occurred.