This is the parent task for the subtasks for Updating payment status
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T113249 [WMDE-Fundraising] Epic: Rewrite of frontend | |||
| Resolved | Tobi_WMDE_SW | T123048 [WMDE-Fundraising] Update credit card payment status | |||
| Resolved | Tobi_WMDE_SW | T130185 [WMDE-Fundraising] Validate credit card data | |||
| Resolved | None | T130186 [WMDE-Fundraising] Add service to determine credit card expiration date | |||
| Resolved | Tobi_WMDE_SW | T130191 [WMDE-Fundraising] Add route and use case for "Update credit card payment status" | |||
| Resolved | gabriel-wmde | T130190 [WMDE-Fundraising] Trigger other data changes when changing donation status |
Event Timeline
Comment Actions
triggers the confirmation mail
So there is a confirmation for creating the donation (AddDonation UC), and then another one for WMDE receiving the payment (this UC)?
Request model parameters:
Is this everything we get send to us, or only the things we actually need?
function (billing for successful transactions; error for failed transactions)
The old code handles value "billing", does some stub thing for "refund" and does nothing for "backpay" (even though that case is explicitly handed). I'm having the impression that the "billing" case represents one UC. "validate credit card billing information"? This does not mean we'd have multiple routes, we can have one route with a switch (which in essence is just more routing) and several UCs. Thoughts?
mcp-handler.php
Based on the code I'm going to guess that mcp stands for micropayment. Is this synonymous to Credit Card payment here? Or has the term some other meaning?
Values that are being stored for documentation purpose only:
...
Values that are being stored for later export:
Is there a need to distinguish between those cases in our code?
Comment Actions
Answering form my own understanding of the code. @kai.nissen, please correct me if I'm wrong.
Request model parameters:
Is this everything we get send to us, or only the things we actually need?
As you can see all the fields will be stored in the data object of the donation. So it looks like we need them all.
The old code handles value "billing", does some stub thing for "refund" and does nothing for "backpay" (even though that case is explicitly handed). I'm having the impression that the "billing" case represents one UC. "validate credit card billing information"? This does not mean we'd have multiple routes, we can have one route with a switch (which in essence is just more routing) and several UCs. Thoughts?
Yeah, that's a good approach. Silex allows for easy sub-requests (request a different route but re-use the current request object/parameters without redirecting).
Based on the code I'm going to guess that mcp stands for micropayment. Is this synonymous to Credit Card payment here? Or has the term some other meaning?
Yeah, the company name is "micropayment GmbH". They are a payment provider that accepts multiple kinds of payment types, but we only use them for credit cards.
Is there a need to distinguish between those cases in our code?
AFAIK not.
Comment Actions
A confirmation mail is only being sent after the transaction is complete. Currently this is triggered when calling the confirmation page.
Request model parameters:
Is this everything we get send to us, or only the things we actually need?
There might be more, but this is what we are using during callbacks.
function (billing for successful transactions; error for failed transactions)
The old code handles value "billing", does some stub thing for "refund" and does nothing for "backpay" (even though that case is explicitly handed). I'm having the impression that the "billing" case represents one UC. "validate credit card billing information"? This does not mean we'd have multiple routes, we can have one route with a switch (which in essence is just more routing) and several UCs. Thoughts?
Sounds reasonable. We can't define different target URLs for the different actions, so having only one route is a requirement.
mcp-handler.php
Based on the code I'm going to guess that mcp stands for micropayment. Is this synonymous to Credit Card payment here? Or has the term some other meaning?
Correct, this only means Micropayment.
Values that are being stored for documentation purpose only:
...
Values that are being stored for later export:Is there a need to distinguish between those cases in our code?
No.
Comment Actions
Can be broken down
- Validate data (20)
- Determine credit card expiration date (20)
- Change status for function == billing (30)
- Handle function == error (10)
- return default result for all other functions
Comment Actions
I've been looking at what the UC should do, and am getting the impression the current title here is still of, and that there are two UCs (though possibly one route):
- ConfirmCreditCardDonationPayment
- HandleCreditCardDonationPaymentError
Is the first one accurate? And if so, any suggestion of how to make the name less long? For the second one I'm a bit fuzzy on what this would need to do, so am not sure this is actually a UC, and not just some thing in the route handler. No subtask was created for that case, was this forgotten or a deliberate choice?