[WMDE-Fundraising] Update credit card payment status
Closed, ResolvedPublic

Description

This is the parent task for the subtasks for Updating payment status

Tobi_WMDE_SW set Security to None.
Tobi_WMDE_SW edited a custom field.
JeroenDeDauw added a subscriber: JeroenDeDauw.EditedMar 14 2016, 5:34 AM

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?

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.

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)?

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.

gabriel-wmde changed the title from "[WMDE-Fundraising] Handle Callback (Credit Card Handler)" to "[WMDE-Fundraising] Update credit card payment status".Mar 16 2016, 1:38 PM

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

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?

Restricted Application added a project: WMDE-Fun-Team. · View Herald TranscriptApr 7 2017, 11:26 AM
Tobi_WMDE_SW closed this task as "Resolved".
Tobi_WMDE_SW claimed this task.