Skip to content

fix(payments): accept strict models, reused instances and string ids - #102

Merged
jfrosorio merged 3 commits into
masterfrom
fix-96
Sep 26, 2026
Merged

jfrosorio merged 3 commits into
masterfrom
fix-96

Conversation

@jfrosorio

Copy link
Copy Markdown
Contributor

Description

Fixes the problems the package review found in the payment classes and traits. Every change is backward compatible.

  • References now store only the model's fillable attributes. The API result also carries keys that are not columns (success, response, and status for Credit Card), which a model with Model::shouldBeStrict() or preventSilentlyDiscardingAttributes() refused after Eupago had already created the payment.
  • create(), status() and refund() (and Credit Card's create()) start with an empty error bag, so hasErrors() on a reused instance reports only the latest operation instead of earlier failures.
  • MBWay and createMbwayReference() take int|string $id, so string order ids work and zero-padded ids reach Eupago unchanged. Integer callers, including under strict_types, keep working.
  • MB and createMbReference() take DateTimeInterface dates, so CarbonImmutable is accepted.
  • refund() URL-encodes the transaction id in the request path.

Each fix has a test that fails without it.

Fixes

This fixes #96.

Copilot AI lite review requested due to automatic review settings September 26, 2026 15:57
@jfrosorio jfrosorio self-assigned this Sep 26, 2026

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟢 Approval recommended

The changes align with the documented issue, are narrowly scoped, and are covered by targeted regression tests for the reported failure modes.

Review effort: Lite
Findings: None

What changed in this PR

This PR addresses several correctness issues in the EuPago payment helpers that were surfaced in issue #96, focusing on compatibility with strict Eloquent models, safe reuse of payment instances, and accepting broader input types for identifiers and dates.

Changes:

  • Persist only model-fillable reference attributes (avoids strict-model failures when API responses include non-column keys).
  • Reset the internal error bag at the start of create(), status(), and refund() (and Credit Card create()) so reused instances report only the latest operation’s errors.
  • Broaden accepted types: MBWay identifiers now accept int|string, MB reference dates now accept DateTimeInterface, and refund() URL-encodes the transaction id in the request path.
File Description
tests/​Feature/​TraitHelpersTest.php Adds regression tests for strict models, immutable dates, and string MB Way ids.
tests/​Feature/​RefundTest.php Adds tests for URL-encoding refund transaction ids and clearing errors on reused instances.
src/​Traits/​HasMultibancoReferences.php Accepts DateTimeInterface for MB reference dates to support immutable dates.
src/​Traits/​HasMbWayReferences.php Accepts `int
src/​Traits/​CreatesEuPagoReferences.php Persists only fillable attributes when creating related reference models.
src/​MBWay/​MBWay.php Updates MB Way identifier typing to `int
src/​MB/​MB.php Accepts DateTimeInterface and formats dates for requests.
src/​EuPago.php Clears errors at operation start and URL-encodes refund transaction id in the request path.
src/​CreditCard/​CreditCard.php Clears errors at Credit Card create() start for reused instances.
docs/​mbway.md Updates docs to reflect identifier is no longer limited to int.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@jfrosorio
jfrosorio merged commit 86ac7c6 into master Sep 26, 2026
17 checks passed
@jfrosorio
jfrosorio deleted the fix-96 branch September 26, 2026 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Payment classes fail with strict models, reused instances and non-integer ids

2 participants