juspay/hyperswitch

[REFACTOR] Integrate the card expiration month/year and security code newtypes in request/response types

Open

#1 012 ouverte le 27 avr. 2023

Voir sur GitHub
 (5 commentaires) (0 réactions) (2 assignés)Rust (4 676 forks)batch import
A-frameworkC-refactorE-easyP-mediumgood first issuehelp wanted

Métriques du dépôt

Stars
 (42 690 stars)
Métriques de merge PR
 (Merge moyen 6j 22h) (213 PRs mergées en 30 j)

Description

Feature Description

Our API models (request/response types) need to be refactored to use the card security code and expiry month/year newtypes added in PR #874.

2 such locations in our codebase are:

https://github.com/juspay/hyperswitch/blob/897250ebc3ee57392aae7e2e926d8c635ac9fc4f/crates/api_models/src/payments.rs#L152

https://github.com/juspay/hyperswitch/blob/897250ebc3ee57392aae7e2e926d8c635ac9fc4f/crates/api_models/src/payment_methods.rs#L77-L83

In other types, the fields might be called cvc, cvv, expiry_month, expiry_year, exp_month, exp_year, etc.

For external contributors, clarify any questions you may have, and let us know that you're interested in picking this up. We'll assign this issue to you to reduce duplication of effort on the same task.

Guide contributeur

Direction de recherche
Tout d'abord, identifiez toutes les occurrences de champs tels que cvc, cvv, expiry month, expiry year, exp month, exp year dans les types de requête/réponse. Ensuite, remplacez leurs types par les newtypes définis dans la PR #874. Assurez vous de mettre à jour les importations et toute utilisation dans les tests. Les fichiers spécifiques à modifier sont crates/api models/src/payments.rs et crates/api models/src/payment methods.rs, mais recherchez également toutes les variantes dans l'ensemble de la crate. Après les modifications, vérifiez la compilation et exécutez les tests pertinents.
Stack technique
rust
Domaine
backendapipayments
Type d'issue
Refactorisation
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
Rust
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60