Integrated drf for DummyProvidor

[jawad-khan]

This PR introduces Django REST Framework (DRF) support for the DummyProvider in django-payments. It adds a DRF Serializer that mirrors the existing DummyForm, enabling API-based validation/usage rather than just form/template-based flows.

[WhyNotHugo]

When an application uses the Form API, the application renders the form, and it will work without any changes regardless of the payment backend being used. With this REST API, it seems that the front end needs to know the appropriate fields for the payment provider, but does it have a way to query which fields or needs to send?

[jawad-khan]

Hi, thanks a lot for your feedback! 🙏

You raise a very valid concern — the frontend needs to know which fields to send when using the REST API. To handle this, one option could be:

Expose a metadata endpoint for each provider that returns field names, types, required/optional status, and available choices.

For example: GET /api/payments/dummy/metadata/ → { "fields": ["status", "fraud_status", "gateway_response", "verification_result"], "choices": {...}, "required": {...} }

Alternatively, we could document how clients can introspect provider serializer fields to discover what’s required.

Or even enhance the serializer to expose a helper for dynamic form generation on the frontend.

This PR was meant as a draft, mainly to get your initial nod before going further. If you think this approach makes sense, I’ll update the PR with:

proper test cases,

the discovery mechanism (metadata endpoint or whichever option you prefer),

and a more complete implementation.

[WhyNotHugo]

Metadata endpoint is best; an API client should be able to reconstruct the form entirely based on this metadata.

[jawad-khan]

Hi @WhyNotHugo, I have added metadata api as you asked. Also improved overall structure of the code. What do you think about this?