@timbro/payments 0.1.0-next.4 → 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -4
- package/dist/generated/openapi.d.ts +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -71,9 +71,12 @@ const refund = await timbro.refunds.create({
|
|
|
71
71
|
The Refund response keeps `allocationIds` and exact `allocationAmounts` so an
|
|
72
72
|
ERP can reconcile one or more split-payer allocations without exceeding any
|
|
73
73
|
captured balance. The Refund row owns the durable provider binding,
|
|
74
|
-
submission fence, and recovery schedule.
|
|
75
|
-
|
|
76
|
-
|
|
74
|
+
submission fence, and recovery schedule. Full, unsplit DOP TEST Azul card refunds
|
|
75
|
+
use the original capture credentials and tax, and confirm approval through
|
|
76
|
+
`VerifyPayment` on a unique refund correlation. TEST CardNet full refunds retain
|
|
77
|
+
the Ztrans submission and same-key inquiry path, pending provider qualification
|
|
78
|
+
in [issue #587](https://github.com/indexa-labs/checkout/issues/587). Partial, split,
|
|
79
|
+
live-mode, wallet, and sandbox paths remain `operator_required` before remote money movement.
|
|
77
80
|
|
|
78
81
|
An authenticated ERP can attach Timbro's accepted E34 fiscal credit note after
|
|
79
82
|
the refund request is recorded. This advances only `fiscalCoordination`; it does
|
|
@@ -184,7 +187,7 @@ resubmission, and `operator_required` means staff must complete or reconcile
|
|
|
184
187
|
the money movement. Provider outcome and fiscal E34 acceptance stay
|
|
185
188
|
independent.
|
|
186
189
|
|
|
187
|
-
|
|
190
|
+
Full, unsplit DOP TEST Azul card refunds submit against the original captured transaction and accepted tax, then confirm the refund amount through `VerifyPayment`. Azul allows one refund per settled transaction within six months; this implementation supports a full refund. CardNet Ztrans full refunds have deterministic recovery tests, while provider refund, inquiry, and settlement qualification remains open in [issue #587](https://github.com/indexa-labs/checkout/issues/587). Partial, split, live-mode, wallet, and sandbox refund paths reserve the requested captured balance and return `operator_required` before remote provider I/O.
|
|
188
191
|
|
|
189
192
|
Before collecting the rest of a merchant's onboarding details, verify its RNC
|
|
190
193
|
against the current DGII directory snapshot. The operation is read-only and
|
|
@@ -308,7 +308,7 @@ export interface paths {
|
|
|
308
308
|
* `refundReference` is the immutable identity of this refund within the merchant and mode. Retrying it with the same caller intent returns the current Refund; changing the intent returns a conflict.
|
|
309
309
|
* Omitting `amount` reserves the remaining captured balance for the selected allocations when the Refund is first created.
|
|
310
310
|
* `source` is optional for ERP coordination. When supplied, its immutable ID and version cannot identify a different Refund.
|
|
311
|
-
*
|
|
311
|
+
* Full, unsplit DOP TEST card refunds through Azul use the original capture credentials and retained tax, with a unique refund correlation and matching VerifyPayment inquiry. CardNet retains its TEST full-refund executor; provider refund and inquiry qualification remains pending. Partial, split, LIVE, wallet, and sandbox paths remain operator_required before remote money movement.
|
|
312
312
|
* A successful provider refund never creates a fiscal credit or debit note; the fiscalCoordination projection is separate.
|
|
313
313
|
* When Idempotency-Key is omitted, the Refund reference supplies a stable retry key. If a key is provided, reuse it for retries. Retrieve the Refund to confirm its current state.
|
|
314
314
|
*/
|