Ok cool, I'll take a look at this tomrrow all being well. Thanks for the feedback
Cheers, Tim Sent from my iPhone On 8 Oct 2009, at 20:43, Ryan Donahue <[email protected]> wrote: > I created the ticket: http://github.com/dpp/liftweb/issues/#issue/88 > > I do receive the payment_status field for PDT. I bet in practice > you will never receive a payment_status value other than Completed, > because if the payment was not completed PayPal would not redirect > the user's browser back to your PDT URL. However, I have not > verified this and do check the payment status in my PDT code anyway > (how could I verify that it will never happen?). So I would prefer > that both were consistent, but just boxing the IPN payment status > will be fine too :) > > On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett <[email protected] > > wrote: > Im not married to the current API, so breaking changes are OK as > there are only a handful of people using this code right now. > > To be honest, this whole situation just underlines the need for > mocking in this module of lift... i've been meaning to do it since > the beginning but just never got round to it and lack of general > demand. > > Just about why they have a different signature... if memory serves > that would be because PaypalTransactionStatus is not supplied for > PDT. So whilst I see your point about them being consistent, im not > sure there is value in having a Box parameter that would always be > Empty? For IPN however, boxing sounds good to me. > > Should just be a case of: > > Box !! info.paymentStatus > > Would you be happy with that? If you could raise a ticket for this > issue i'll patch it tomorrow and commit the code on a branch related > to that ticket. One the code goes through review then it will make > it into the master branch all being well. > > Cheers, Tim > > > On 8 Oct 2009, at 18:52, Ryan Donahue wrote: > >> Yeah, I noticed my email got mangled. >> >> It would make sense to me if PaypalIPN.actions and >> PaypalPDT.pdtResponse were consistent. >> >> trait PaypalPDT { >> def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse] >> } >> >> trait PaypalIPN { >> def actions: PartialFunction[(PayPalInfo, Req), Unit] >> } >> >> If matching the status is just too convenient to lose, then how >> about this. >> >> trait PaypalPDT { >> def pdtResponse: PartialFunction[(Box >> [PaypalTransactionStatus.Value], PayPalInfo, Req), LiftResponse] >> } >> >> trait PaypalIPN { >> def actions: PartialFunction[(Box[PaypalTransactionStatus.Value], >> PayPalInfo, Req), Unit] >> } >> >> Either would be an API breaking change for the paypal module, but >> at least it'd be caught be the compiler. What do you think? >> >> On Thu, Oct 8, 2009 at 1:33 PM, Timothy Perrett <[email protected] >> > wrote: >> >> The parameters were pretty mangled in your email... Which one would >> you propose is more generic that the current status one we have? >> Alternatively, it sounds to me like we might need to add some kind of >> special case match statement. >> >> Thoughts? >> >> Cheers, tim >> >> On 8 Oct 2009, at 13:14, Ryan Donahue wrote: >> >> > >> > Hi Tim, >> > >> > Looking at "Table 2. Summary of subscription variables" of the page >> > you reference, payment_status is not included for messages with a >> > txn_type of subscr_ signup, subscr_ cancel, subscr_ modify, or >> > subscr_eot. >> > >> > This matches the results I see in testing with PayPal Sandbox. >> > Neither subscr_signup or subscr_cancel include the payment_status. >> > Below are the parameters from two messages I have received (they >> > contain fake user info generated by PayPal Sandbox, so no security/ >> > privacy concerns). >> > >> > params from subscr_signup message: >> > btn_id -> List(1070963), test_ipn -> List(1), charset -> List >> > (windows-1252), address_country -> List(United States), item_name >> -> >> > List(Pro Account), recurring -> List(1), address_state -> List(CA), >> > amount3 -> List(9.99), address_street -> List(1 Main St), >> > verify_sign - >> >> List(Ab4im9HUsk1pOL1dlUXJxEoipQcaAJQqV047JE2KENGFX4meCETo.KLt), >> > address_status -> List(confirmed), period3 -> List(1 M), >> subscr_date - >> >> List(05:01:02 Oct 08, 2009 PDT), first_name -> List(Test), >> > address_country_code -> List(US), address_city -> List(San Jose), >> > mc_currency -> List(USD), mc_amount3 -> List(9.99), >> > residence_country - >> >> List(US), payer_email -> List([email protected]), >> > address_name -> List(Test User), txn_type -> List(subscr_signup), >> > payer_status -> List(verified), subscr_id -> List >> > (S-8X87353621486401E), last_name -> List(User), payer_id -> List >> > (JMM2RTLNU5RPJ), reattempt -> List(1), notify_version -> List(2.8), >> > custom -> List(2), address_zip -> List(95131), receiver_email -> >> List >> > ([email protected]), business -> List >> > ([email protected]) >> > >> > params from subscr_cancel message: >> > btn_id -> List(1070963), test_ipn -> List(1), charset -> List >> > (windows-1252), address_country -> List(United States), item_name >> -> >> > List(Pro Account), recurring -> List(1), address_state -> List(CA), >> > amount3 -> List(9.99), address_street -> List(1 Main St), >> > verify_sign - >> >> List(AvpXEetWAO5JsntihTfwE4HykmNlAsappICrYh6PaVgG3JJUYLtOnqVU), >> > address_status -> List(confirmed), period3 -> List(1 M), >> subscr_date - >> >> List(05:06:19 Oct 08, 2009 PDT), first_name -> List(Test), >> > address_country_code -> List(US), address_city -> List(San Jose), >> > mc_currency -> List(USD), mc_amount3 -> List(9.99), >> > residence_country - >> >> List(US), payer_email -> List([email protected]), >> > address_name -> List(Test User), txn_type -> List(subscr_cancel), >> > payer_status -> List(verified), subscr_id -> List >> > (S-8X87353621486401E), last_name -> List(User), payer_id -> List >> > (JMM2RTLNU5RPJ), reattempt -> List(1), notify_version -> List(2.8), >> > custom -> List(2), address_zip -> List(95131), receiver_email -> >> List >> > ([email protected]), business -> List >> > ([email protected]) >> > >> > Thanks, >> > >> > Ryan >> > >> > On Oct 7, 6:18 pm, Timothy Perrett <[email protected]> wrote: >> >> Ryan, >> >> >> >> The PayPal stuff is pretty much my baby - its awesome that your >> using >> >> it in production! >> >> >> >> See what your saying - its been a while since I did anything with >> >> PayPal; what fields *are* returned when the transaction is >> canceled? >> >> Or, specifically, the question is what behaviour do you need? >> >> >> >> Lets start there and then I can work on a solution - it was my >> >> understanding that all responses from paypal had the >> payment_status >> >> field; im using the reference here:http://is.gd/43po4can you >> detail >> >> the type of transaction you've been seeing this behaviour on? >> >> >> >> Cheers, Tim >> >> >> >> On 7 Oct 2009, at 20:56, Ryan Donahue wrote: >> >> >> >> >> >> >> >>> I'm receiving IPN updates from PayPal when a subcription is >> created >> >>> and when it is canceled. However, the cancel message never make >> >>> it to >> >>> my actions method. Apparently, the cancel message does not >> include >> >>> the payment_status. I think this results in the message being >> >>> dropped >> >>> on the floor because of the for-comprehension on line 458 in >> >>> Paypal.scala. Would appreciate any help. By the way, we've been >> >>> using the paypal module in production for a couple months now (a >> >>> very >> >>> small app for selling a partner-branded version of our screen >> >>> recorder). >> >> >> >>> Thanks, >> >> >> >>> Ryan >> > > >> > >> >> >> >> >> >> > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
