A partial refund leaves two questions for a digital shop. How much money has been returned, and what access should the buyer retain? The amount alone cannot answer the second question. A goodwill adjustment might preserve the whole download, while a refund for one item in a bundle needs an item-level decision.
StableIn's local demonstration records a 30 test-USDC refund followed by 70 test USDC against a 100 test-USDC payment. Source inspection also shows a merchant fulfillment example with one entitlement per order. It does not show a mechanism for revoking an issued entitlement or recalling a downloaded file. The access model below is an extension proposal built around that boundary.
Read the implemented refund behavior first
The refund service requires a finalized paid order before creating a refund request. It subtracts completed refunds and outstanding, non-abandoned requests from the original amount when checking the remaining refundable balance. Repeating a merchant refund reference with a different amount returns a conflict.
This gives the money operation a useful identity. A request can still require the owner's action and a transaction before it completes. The application should preserve that distinction when deciding when to apply an access policy. Treating the initial request as completed would move the access decision ahead of the payment evidence.
The merchant example already has a narrower fulfillment rule. It allows fulfillment when payment is paid, the refund is not full, the refunded amount is below the order amount, and the fetched revision is sufficiently current. Partial refund therefore does not automatically block the example's initial entitlement.
When the current order no longer qualifies, pending or leased fulfillment work is cancelled. The worker fetches the current platform order before creating a unique shipment record. Existing shipment records are retained. This is evidence for controlling delivery that has not happened yet, with no claim that delivered access is withdrawn.
Give the access decision its own record
For a real download service, add an entitlement record with a stable ID and a link to the original order item. Suggested fields include an access status, the policy version used, the reason for a change and the responsible operator or automated rule. Record the refund that prompted the decision without using the refund status as the access status itself.
Start with the merchant's actual rules. A single downloadable archive may only support keeping or blocking future downloads. A bundle sold as separately identified items can support removing one item's future access while retaining the others. That requires item-level entitlement data; a percentage refund does not supply the missing item identity.
| Situation | Money record | Proposed access decision |
|---|---|---|
| Partial goodwill refund | Completed partial amount | Keep access under the recorded policy |
| Full refund before delivery | Completed full amount | Cancel pending delivery |
| Refund for one bundle item | Item allocation plus refund ID | Review that item's future access |
| Full refund after download | Completed full amount | Decide future access; retain download history |
| Disputed entitlement change | Refund and operator evidence | Hold for review with an accountable owner |
The table offers decisions to agree during implementation. It does not describe additional StableIn features already delivered.
Make future download checks explicit
A proposed download endpoint should look up the current entitlement before issuing access. If it returns a signed storage URL, the URL's own lifetime becomes another part of the access policy. Changing a database flag does not by itself change a capability already issued by another service.
For example, Amazon S3 documents that a presigned URL can be reused until expiry, subject to the signing credentials and permissions. S3 checks expiry when a request begins, and a download started before expiry can continue afterward. This is a storage-specific behavior to account for if S3 is selected; it is not an implemented StableIn integration.
Define a maximum lifetime for new download links and document how existing links behave after an entitlement change. Preserve the fact that a file already transferred to the buyer cannot be recalled through your server's access flag. An access audit should show what the service can still control.
Review the refund and delivery race
Use the worksheet to walk through a full refund while delivery is waiting, a partial refund before first delivery, and a refund after an entitlement exists. Include a delayed payment notification that arrives after a newer refund revision. The expected access result must come from the agreed policy and the newest verified order state.
All worksheet cases are marked Not run. They should produce evidence for the eventual implementation, including the refund ID, entitlement state and a fresh download attempt. Historical screenshots of partial refunds establish the local money flow only.
Download the refund and entitlement decision matrix.
StableIn Payments uses local test assets in its demonstration. Bring the delivery mechanism and refund responsibilities to a project discussion so the additional access controls can be scoped precisely.
