Release 0.6.0 through 0.7.0: security, reliability, and typing

[shihweilo]

Brings the library from 0.5.2 to 0.7.0 across four commits. The first lands the
Pydantic migration that was sitting uncommitted in the working tree; the rest
address findings from a review of the client.

Every commit passes its own tests in isolation, verified in a clean worktree.

Commits

Commit	Release	Summary
c827699	0.6.0	Migrate CardHolderData to Pydantic v2
3129e5a	0.6.1	Request timeouts, log redaction, version single-sourcing, py.typed
fd412ca	0.7.0	Pooled session, selective retries, raise_on_error, currency selection
84076f6	0.7.0	InvalidResponseError on a malformed 2xx body

Highlights

Credentials and cardholder PII no longer reach logs. Debug logging previously
emitted the x-api-key partner key, the full request body (partner_key,
prime, card_key, card_token, and the entire cardholder block), and the raw
response body including card_secret and card_info. Any application running at
DEBUG was writing payment credentials and personal data to its logs. These are
now redacted before reaching the logger, matched case-insensitively at any depth,
and the log records are built lazily so nothing is computed when debug is off.

Requests now carry a timeout. There was none, so a stalled TapPay endpoint
could block the calling thread indefinitely and exhaust a web application's
worker pool. Defaults to (3.05, 27.0) seconds, overridable per client and per
call.

Retries are deliberately selective. Only the read-only query endpoints retry.
Payment, refund, capture, bind and remove endpoints never do: TapPay exposes no
idempotency key, so retrying a request that actually succeeded upstream would
charge the cardholder twice. A test asserts max_retries.total == 0 across every
write path so the guarantee cannot silently regress.

Business failures can now surface as exceptions. TapPay reports declines with
an HTTP 200 and a non-zero status, invisible to HTTP-level error handling.
raise_on_error=True raises TapPayError; it defaults to False so existing
callers are unaffected.

Connection pooling. A per-client requests.Session replaces module-level
requests.post, so repeated calls reuse an established TLS connection rather
than renegotiating one each time.

Also: py.typed (PEP 561), a single-sourced version (__version__ reported
0.5.2 while the package was 0.6.0), currency selection, close() and context
manager support, a dev extra, mypy in CI, and Python 3.13 in the matrix.

Test coverage

73% to 100% (235 statements), 82 tests. ruff and mypy clean.

Breaking changes

1. CardHolderData requires keyword arguments (0.6.0). Positional
   construction raises TypeError. EmailStr is also stricter than the plain
   str field it replaced. Migration guide is in CHANGELOG.md.
2. Tests mocking tappay.client.requests.post will no longer intercept
   anything (0.7.0). Requests now go through client.session.post; patch that
   instead.
3. Models.Currencies is now a str enum. Members still compare equal to
   their string form and still serialize as "TWD" through json.dumps, but
   str() and f-strings render them as Currencies.TWD on Python 3.11+, so a
   member must never be interpolated into a request payload. A test pins this.

Review notes

• CI is split into a quality job (ruff + mypy on one interpreter) and a test
  matrix. Current mypy releases cannot target Python 3.8, and type checking does
  not need to repeat across every interpreter.
• The Python 3.8 matrix entry is the most likely CI failure here: 3.8 is EOL and
  now actively constrains tooling. If it fails to resolve dependencies, that is
  an argument for raising the floor to 3.9+ rather than working around it.
• InvalidResponseError messages deliberately omit the response body. Exception
  text routinely reaches logs and error trackers, and an unparseable body cannot
  be redacted by key the way a JSON payload can.

Not included

Async client, response models, the Python 3.8 floor bump, and renaming the
_dict-suffixed get_records parameters.

🤖 Generated with Claude Code