Skip to content

feat: add authorization_type and payment_plan to payment request classes#213

Open
armando-rodriguez-cko wants to merge 1 commit into
mainfrom
fix/payment-request-field-gaps
Open

feat: add authorization_type and payment_plan to payment request classes#213
armando-rodriguez-cko wants to merge 1 commit into
mainfrom
fix/payment-request-field-gaps

Conversation

@armando-rodriguez-cko

Copy link
Copy Markdown
Contributor

Summary

Aligns three payment request classes with the swagger spec, which added authorization_type and payment_plan:

  • HostedPaymentsSessionRequest (swagger HostedPaymentsRequest)
  • PaymentLinkRequest (swagger PaymentLinksRequest)
  • PaymentSessionsRequest (swagger CreatePaymentSessionsBaseRequest)

Both attributes reuse existing types from checkout_sdk.payments.payments: the AuthorizationType enum and the PaymentPlan hierarchy (already used by PaymentRequest). The JSON serializer emits attribute names directly, so the fields are named authorization_type and payment_plan to match the API.

Part of a cross-SDK sweep to close request-field gaps surfaced by the swagger changelog (entries 2026-06-03 and 2026-06-15).

Tests

Added tests/payments/payment_request_fields_serialization_test.py verifying both fields serialize correctly for all three request classes.

python -m pytest tests/payments/ -k "not integration"
70 passed, 104 deselected

Align HostedPaymentsSessionRequest, PaymentLinkRequest and
PaymentSessionsRequest with the swagger spec, which added
authorization_type and payment_plan to HostedPaymentsRequest,
PaymentLinksRequest and CreatePaymentSessionsBaseRequest.

Reuses the existing AuthorizationType enum and PaymentPlan type from
checkout_sdk.payments.payments. Adds serialization tests covering all
three request classes.
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant