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 <timo...@getintheloop.eu>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(buyer1_1254939630_...@gmail.com),
> > 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
> > (seller_1254749970_...@gmail.com), business -> List
> > (seller_1254749970_...@gmail.com)
> >
> > 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(buyer1_1254939630_...@gmail.com),
> > 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
> > (seller_1254749970_...@gmail.com), business -> List
> > (seller_1254749970_...@gmail.com)
> >
> > Thanks,
> >
> > Ryan
> >
> > On Oct 7, 6:18 pm, Timothy Perrett <timo...@getintheloop.eu> 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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to