Post-Sale Operations
Manage the lifecycle of a booked transaction: void an uncaptured authorisation, capture a pre-auth, refund a settled charge, or run a recurring / MIT charge against a stored token — all through the EdfaPgSdk facade.
Operations
void, capture, and refund take a transaction id (and an amount for capture / refund); recurring takes a RecurringRequest. All are asynchronous and return the gateway response.
Semantics
Each operation has a pre-condition on the original transaction's state.
| Operation | Pre-condition | What it does |
|---|---|---|
| void (Flutter: voidd) | Authorised, not yet captured / settled. | Cancels the authorisation. |
| capture | Pre-authorised (sale with auth = "Y"). | Settles up to the authorised amount (partial allowed). |
| refund | Captured / settled. | Returns funds, partial or full. |
| recurring | Initial sale enrolled with recurringInit = "Y". | Charges using the stored recurringToken. |
Flutter naming
void is a reserved keyword in Dart, so the Flutter facade names the method voidd. The other three keep their names.
Recurring / MIT
recurring charges a card enrolled during the initial sale (recurringInit = "Y"). Pass the original transactionId, the stored recurringToken, the amount, and an Order describing the charge.
Loading...Not idempotent
recurring is not idempotent by default. Pre-generate a unique order number and query the gateway before retrying a timed-out call so you don't double-charge.
On this page
Downloads
Coming SoonSample apps, release bundles, and more content will be available here soon.