That's a reasonable question that we'd entertained ourselves before we settled on the current solution, and the answer will be a bunch of "inside baseball", but here's the nitty-gritty details if you're curious.



For one thing, buyers could enter a Shipping address in 2CO that differs from the shipping country and postal code they'd entered in the cart for shipping calculation before checkout, and unlike PayPal (and the late Google Checkout), 2CO has no way to callback to our system to recalculate Shipping charges based on the actual address entered at their end.



We also discovered that if we don't pre-collect Shipping address details to send 2CO, they would ignore any shipping amounts our cart would calculate and pass to them; instead, they'd apply shipping calculation rules (if any) defined at their end. We didn't want our sellers having to deal with the complexities of differing shipping calculation settings at each end which would likely calculate conflicting amounts in many cases and thereby confuse or annoy buyers as well.



To get around all that, since we're collecting a Shipping address to pass 2CO, we decided to also collect the Billing Address at our end, so buyers could do the simple "Shipping same as Billing" checkbox, and this also lets us "lock in" whatever shipping country and postal code they'd entered in the cart for shipping calculation before checkout.



When we transfer the buyer to 2CO, we also tell 2CO's checkout page to skip the address sections at their end and go straight to the Payment Information panel. While it's possible for buyers to re-expand the address panels at 2CO and change the address there, we do a comparison once 2CO completes the payment and sends the order details back to us.



If the country/postal got changed at checkout and doesn't match what was used to calculate tax/shipping in the cart beforehand, we include a "Possible Shipping/Tax Fraud!" warning in the Sale Notification email we send you, so you can examine the discrepancy and decide how to handle the situation yourself. BTW, this is similar to the situation with all PayPal sales up until a couple years ago, when they finally implemented a recalculation callback routine, so we'll be pressing 2CO to add support for something similar.



We also looked into implementing 2CO's new "Direct Checkout" payment panel (sans address fields) that would appear as an overlay in our own address-collection page, similar to how our cart works inside your site. However, not only were we unable to get this working well enough for testing before the Nov. 20th deadline due to technical conflicts, there's also a serious limitation to this method which would make it unsuitable for us and our sellers anyway.



That limitation was, if a given buyer's browser happens to block third-party cookies (as many people do for security/privacy concerns, and as modern browsers increasingly do by default, including Safari and now Firefox), this Direct Checkout payment panel would only work at all if that seller had selected the "Given links back to my site" return method in 2CO, rather than the auto-redirecting Header Redirect method we'd prefer. Not only would the Given Links method fail to auto-redirect buyers to their thank-you/download page after payment, but if the buyer neglected to click that return link after their payment had already been completed, 2CO would never send any order details back to our system at all, so our system would then have no way of knowing the order had actually been placed and paid-for vs., say, abandoned during checkout.

I'll have to confirm this with Development, but I think the problem may be that 2CO has no way of notifying us when they refund/reverse/cancel/void a payment. Their initial notification of payment occurs as an inherent part of redirecting the buyer from 2CO checkout to our thank-you page, but I'm pretty sure that transition is the only way they can transmit any notification to our system.



Our Transaction Log is only intended as an order history and should not be used for financial tracking or accounting purposes, as all of the information we can show there is "secondhand", reflecting whatever the payment processor (e.g. PayPal or 2CO) reported to us (or failed to report, as the case may be). If you have concerns about any actual funds paid, reversed, or refunded, you should rely on your payment processor account's records (e.g. 2CO Sales history) to get that data straight from the source, use that history as your primary financial/accounting reference for online sales, and consult the payment processor's help pages or support staff with any further questions you may have about anything you find there.

Yes, that would also be correct, so you'd need to keep an eye out for any 2CO refunds and deduct those commissions from affected affiliates' monthly commission totals before you pay them out. The "masspay.txt" monthly commission report we generate is a plaintext file you can open and edit in any plaintext editor like Notepad or TextEdit; it should be pretty simple to amend the amounts listed there if/as needed, before you upload the file to PayPal Mass Payment.