PayPal Express Checkout Datamodel

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

PayPal Express Checkout Datamodel

Scott Gray-2
Hi All,

In order to be able to perform a full checkout with PayPal's Express  
Checkout you are required to send 1 or more 'default' shipping methods/
estimates along with the request that initiates the checkout.  It's a  
bit of a PITA because you don't yet know the shipping address but are  
required to provide estimates anyway.

Later in the checkout process PayPal sends you the shipping address as  
soon as it is known and requests a new list of shipment methods/
estimates.  If and only if that communication fails or times out (6  
seconds) are 'default' shipping methods/estimates used.

So I'm trying to figure out the best way to get these default shipment  
methods into the data model without affecting anything else, here's  
some options so far:
1.  Create a new entity which is a join of PaymentGatewayConfigPayPal  
and ShipmentCostEstimate and avoid the shipment estimate services.  I  
haven't looked into how I could force a certain shipment cost when  
creating the order yet.
2.  Add an estimateWithoutGeo field to ProductStoreShipmentMethod (or  
perhaps to ShipmentCostEstimate) and support for it to the shipment  
estimate services which allows an estimate to be calculated without  
knowing the destination.

Any thoughts? Other suggestions?

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PayPal Express Checkout Datamodel

BJ Freeman
I would approach it from the user level and ask for there paypal address
of record first.
i would then build the Shipping estimate tables so they are access fast.
note: this is a change from the manual maintainance of the shipping
estimate tables.
Then i would call paypal.
on the return request would do check if the address changed, if not then
use the previous.
would then check for for the zipcode to see if in same rate table, which
usually it is, then return the previous tables.
my experience in building the shipping estimates for USPS and UPS for a
 rate table based on a zipcode is under a few seconds.
using the shipping estimate service should not be more than a few milli
seconds if the data is already there.
Also using this method once a rate table is built it is good for about 6
months.


Scott Gray sent the following on 8/4/2009 3:13 PM:

> Hi All,
>
> In order to be able to perform a full checkout with PayPal's Express
> Checkout you are required to send 1 or more 'default' shipping
> methods/estimates along with the request that initiates the checkout.
> It's a bit of a PITA because you don't yet know the shipping address but
> are required to provide estimates anyway.
>
> Later in the checkout process PayPal sends you the shipping address as
> soon as it is known and requests a new list of shipment
> methods/estimates.  If and only if that communication fails or times out
> (6 seconds) are 'default' shipping methods/estimates used.
>
> So I'm trying to figure out the best way to get these default shipment
> methods into the data model without affecting anything else, here's some
> options so far:
> 1.  Create a new entity which is a join of PaymentGatewayConfigPayPal
> and ShipmentCostEstimate and avoid the shipment estimate services.  I
> haven't looked into how I could force a certain shipment cost when
> creating the order yet.
> 2.  Add an estimateWithoutGeo field to ProductStoreShipmentMethod (or
> perhaps to ShipmentCostEstimate) and support for it to the shipment
> estimate services which allows an estimate to be calculated without
> knowing the destination.
>
> Any thoughts? Other suggestions?
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Reply | Threaded
Open this post in threaded view
|

Re: PayPal Express Checkout Datamodel

Scott Gray-2
Thanks for your input BJ, a few points:
1.  If you ask for the shipping address first you are no longer doing  
a full checkout process and might as well just take the PayPal as a  
payment method option.  The point of offering Express Checkout is that  
for a PayPal user it is 'express', they log in select a shipping  
address, confirm the payment and they're done.
2.  Building some sort of rate table might work for some custom  
implementations but it does not work for OFBiz, we support a vast  
number of approaches to shipping estimates such as weight breaks,  
quantity breaks, price breaks, geo restrictions, a number of external  
estimates and the potential for more.

I'm not particularly concerned about the 6 second timeout (although I  
will be testing it) and I think it is fairly unlikely that these  
default shipping options will ever appear but regardless they need to  
be taken into account and modeled.

Regards
Scott

On 5/08/2009, at 10:04 PM, BJ Freeman wrote:

> I would approach it from the user level and ask for there paypal  
> address
> of record first.
> i would then build the Shipping estimate tables so they are access  
> fast.
> note: this is a change from the manual maintainance of the shipping
> estimate tables.
> Then i would call paypal.
> on the return request would do check if the address changed, if not  
> then
> use the previous.
> would then check for for the zipcode to see if in same rate table,  
> which
> usually it is, then return the previous tables.
> my experience in building the shipping estimates for USPS and UPS  
> for a
> rate table based on a zipcode is under a few seconds.
> using the shipping estimate service should not be more than a few  
> milli
> seconds if the data is already there.
> Also using this method once a rate table is built it is good for  
> about 6
> months.
>
>
> Scott Gray sent the following on 8/4/2009 3:13 PM:
>> Hi All,
>>
>> In order to be able to perform a full checkout with PayPal's Express
>> Checkout you are required to send 1 or more 'default' shipping
>> methods/estimates along with the request that initiates the checkout.
>> It's a bit of a PITA because you don't yet know the shipping  
>> address but
>> are required to provide estimates anyway.
>>
>> Later in the checkout process PayPal sends you the shipping address  
>> as
>> soon as it is known and requests a new list of shipment
>> methods/estimates.  If and only if that communication fails or  
>> times out
>> (6 seconds) are 'default' shipping methods/estimates used.
>>
>> So I'm trying to figure out the best way to get these default  
>> shipment
>> methods into the data model without affecting anything else, here's  
>> some
>> options so far:
>> 1.  Create a new entity which is a join of PaymentGatewayConfigPayPal
>> and ShipmentCostEstimate and avoid the shipment estimate services.  I
>> haven't looked into how I could force a certain shipment cost when
>> creating the order yet.
>> 2.  Add an estimateWithoutGeo field to ProductStoreShipmentMethod (or
>> perhaps to ShipmentCostEstimate) and support for it to the shipment
>> estimate services which allows an estimate to be calculated without
>> knowing the destination.
>>
>> Any thoughts? Other suggestions?
>>
>> Thanks
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>
> --
> BJ Freeman
> http://www.businessesnetwork.com/automation
> http://bjfreeman.elance.com
> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
> Systems Integrator.
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PayPal Express Checkout Datamodel

BJ Freeman
In reply to this post by BJ Freeman
#1 I guess you going for the minimal model for paypal like in the IPN.
   I was tryng to get across that if they select and Address is should
be one they have on file with paypal or is their address on their CC.
This is for Paypal to guarantee the payment.
#2 this is actually a re-factor of the services that are done nightly to
build Shipping estimates from the Shippers on a nightly basis. so Only
if and Address, and/or Geo code is new is any data created.
of course I did pre-load of these for all the US delivery points.
But I don't see why it can't be part of ofbiz like the Taxinfo is.

Scott Gray sent the following on 8/5/2009 3:29 AM:

> Thanks for your input BJ, a few points:
> 1.  If you ask for the shipping address first you are no longer doing a
> full checkout process and might as well just take the PayPal as a
> payment method option.  The point of offering Express Checkout is that
> for a PayPal user it is 'express', they log in select a shipping
> address, confirm the payment and they're done.
> 2.  Building some sort of rate table might work for some custom
> implementations but it does not work for OFBiz, we support a vast number
> of approaches to shipping estimates such as weight breaks, quantity
> breaks, price breaks, geo restrictions, a number of external estimates
> and the potential for more.
>
> I'm not particularly concerned about the 6 second timeout (although I
> will be testing it) and I think it is fairly unlikely that these default
> shipping options will ever appear but regardless they need to be taken
> into account and modeled.
>
> Regards
> Scott
>
> On 5/08/2009, at 10:04 PM, BJ Freeman wrote:
>
>> I would approach it from the user level and ask for there paypal address
>> of record first.
>> i would then build the Shipping estimate tables so they are access fast.
>> note: this is a change from the manual maintainance of the shipping
>> estimate tables.
>> Then i would call paypal.
>> on the return request would do check if the address changed, if not then
>> use the previous.
>> would then check for for the zipcode to see if in same rate table, which
>> usually it is, then return the previous tables.
>> my experience in building the shipping estimates for USPS and UPS for a
>> rate table based on a zipcode is under a few seconds.
>> using the shipping estimate service should not be more than a few milli
>> seconds if the data is already there.
>> Also using this method once a rate table is built it is good for about 6
>> months.
>>
>>
>> Scott Gray sent the following on 8/4/2009 3:13 PM:
>>> Hi All,
>>>
>>> In order to be able to perform a full checkout with PayPal's Express
>>> Checkout you are required to send 1 or more 'default' shipping
>>> methods/estimates along with the request that initiates the checkout.
>>> It's a bit of a PITA because you don't yet know the shipping address but
>>> are required to provide estimates anyway.
>>>
>>> Later in the checkout process PayPal sends you the shipping address as
>>> soon as it is known and requests a new list of shipment
>>> methods/estimates.  If and only if that communication fails or times out
>>> (6 seconds) are 'default' shipping methods/estimates used.
>>>
>>> So I'm trying to figure out the best way to get these default shipment
>>> methods into the data model without affecting anything else, here's some
>>> options so far:
>>> 1.  Create a new entity which is a join of PaymentGatewayConfigPayPal
>>> and ShipmentCostEstimate and avoid the shipment estimate services.  I
>>> haven't looked into how I could force a certain shipment cost when
>>> creating the order yet.
>>> 2.  Add an estimateWithoutGeo field to ProductStoreShipmentMethod (or
>>> perhaps to ShipmentCostEstimate) and support for it to the shipment
>>> estimate services which allows an estimate to be calculated without
>>> knowing the destination.
>>>
>>> Any thoughts? Other suggestions?
>>>
>>> Thanks
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>
>> --
>> BJ Freeman
>> http://www.businessesnetwork.com/automation
>> http://bjfreeman.elance.com
>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
>>
>> Systems Integrator.
>>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.