View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011701 | Taler | taler-rust | public | 2026-07-30 09:08 | 2026-08-29 19:08 |
| Reporter | Antoine A | Assigned To | Antoine A | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | none | Severity | feature | Reproducibility | N/A |
| Status | implementing | Resolution | open | ||
| Target Version | post-2.0 | ||||
| Summary | 0011701: taler-wise: incoming transaction webhook support | ||||
| Description | Support for “https://docs.wise.com/api-reference/webhook-event/eventincomingtransfercredited” to record incoming transfers. This provides us with an incoming transfer ID that allows us to obtain more comprehensive and better-structured information about these transfers, which is available only via Webhooks and not included in balance statements. The Wise API recommends this method, but I don’t like it because it make possible missing some incoming transactions in case of downtime. We should evaluate whether it’s better to use only webhooks or if the two sources of information can be reconciled. We need to test if non SWIFT transfer also triggers the webhook. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-07-30 09:08 | Antoine A | New Issue | |
| 2026-07-30 09:08 | Antoine A | Status | new => assigned |
| 2026-07-30 09:08 | Antoine A | Assigned To | => Antoine A |
| 2026-07-30 09:08 | Antoine A | Description Updated | |
| 2026-08-29 19:08 | Florian Dold | Target Version | => post-2.0 |
| 2026-11-03 07:21 | Status | assigned => implementing |