#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.

Reply via email to