If these lower-dollar amounts have to be charged against a different merchant ID, I imagine that will make life harder for Donor Services as well. @MBeat33 has described PayPal's transaction management UI as pretty painful already, even without having to search twice for donations or log in and out of multiple merchant accounts.

Thanks @Ejegg If PayPal would be unable to combine the two merchant IDs in the same console/account, that would definitely complicate donor services workflows.

Paypal further explains: You would need to have two separate PayPal accounts because pricing is done on the account level not on a per transaction level. So we would need to integrate 2 separate flows, one for the <$6 goes to account A and >$6 goes to account B. We would not be able to have the flows mix. However, I want to clarify the terminology we are all using:

1. When PP says we need two integrations, they essentially mean we would have to have two separate FLOWS, the less than $6 and the over than $6 flows pointed two two different accounts and not two distinct technical connections. The separation of the volume by ticket size is work that would be on us but both could use the same technical pipe. I would work with them to setup the account structure we need on their end.
2. As far as Donor Services would be concerned, I checked on this and we could satisfy them seeing the two 'flows' in the single account by creating a Master account with two subordinate accounts. This would keep them from needing two log ins.

Just wanted to make this clear for FR Tech's further consideration.

Thanks, if the two flows can show in the same console that's peachy.

OK, looks like the payments-wiki side would be pretty easy. Our base adaptor class has logic for switching accounts depending on transaction data (we needed it for WorldPay).

• Add a 'microtransaction' account config to $wgPaypalExpressGatewayAccountInfo based on the 'prod' one. (6 lines of config)
• Override findAccount in the express checkout adaptor to take the amount into account and select the 'microtransaction' one for low-dollar txns. (~10 lines of code, maybe 20 lines of test)
• Add the new account's cert and password to production puppet.

@EMartin, thanks for the quick info today! Could you please ask whether we would need to parse two sets of audit/reconciliation files each night, or if all of the transactions would be in the master account's files?

@Ejegg It is feasible for the main account to be used for central clearing/settlement/fundng as the integration and bank are attached. Once the accounts are created , we can set them to automatically clear out funds to the master account at a daily basis. The transactions are still related to the sub account, but the full amount is transferred in a lump sum, and not on a transaction by transaction basis. Once those funds are transferred, the master account can then automatically withdraw funds the same as it is doing today.

@Ejegg @DStrine As we are embarking on the Braintree project in the next few weeks, I am working with Paypal to discuss the new pricing scheme as above. In a call today they advise that it will be up to WMF to segregate the transactions based on amount and process through two distance Paypal accounts; those under the low threshold for percentage based pricing and those over the threshold for % fee + per item fee. Paypal would like to have a call with us to discuss best approach on this as they have guided other merchants through this before. Please let me know when we could have this call with Paypal and also kick off meeting their technical lead in supporting our reintegration. Thanks