You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Transactions::get() throws ValueError for card type BANCOMAT #127
For a card-present transaction paid with an Italian PagoBancomat debit card, the Transactions API returns "card": { "type": "BANCOMAT", ... }.
BANCOMAT is not a case of SumUp\Types\CardResponseType (nor of CardType in openapi.json), so Hydrator::castEnumValue() falls back to from() and throws a ValueError. The whole TransactionFull is lost, although the transaction is SUCCESSFUL and every other field is valid.
In a Solo / Cloud API integration this means an approved payment cannot be reconciled through Transactions::get(): in our case the payment stayed unresolved and the reader was blocked until we worked around it.
Expected: the transaction is returned. BANCOMAT should be a known card type, and in general an enum value added to the API before the SDK is regenerated should not make the whole response unreadable. CardResponseType already declares an UNKNOWN case that could absorb it.
I'm opening a PR with a fix: a fallback to the UNKNOWN case in the hydrator (enums without UNKNOWN keep the current strict behaviour) and BANCOMAT added to the CardType schema.
We hit the same issue today with sumup/sumup-php 0.1.6 in a CiviCRM Solo / Cloud API integration, but the unexpected value was card.type = "SUMUP" rather than BANCOMAT.
The resulting ValueError prevented us from hydrating and reconciling an otherwise successful transaction. We worked around it in our integration by normalising unknown CardResponseType values to UNKNOWN before hydration.
This confirms that the generic UNKNOWN fallback in #128 is useful beyond the specific BANCOMAT case.
Activity
jonathandhn commentedon Oct 14, 2026
We hit the same issue today with
sumup/sumup-php0.1.6 in a CiviCRM Solo / Cloud API integration, but the unexpected value wascard.type = "SUMUP"rather thanBANCOMAT.The resulting
ValueErrorprevented us from hydrating and reconciling an otherwise successful transaction. We worked around it in our integration by normalising unknownCardResponseTypevalues toUNKNOWNbefore hydration.This confirms that the generic
UNKNOWNfallback in #128 is useful beyond the specificBANCOMATcase.matoous commentedon Oct 15, 2026
Fix(es) released in v0.1.7. Thank you for reporting.