I have an answer about how Paypal calculates the fees to apply to each receiver in case of a chained or parallel payment done with the Adaptive Payment API.
Is the fee calculated on the total amount payed by the sender? In this case each receiver would pay a proportional portion of the total fee. Or is it charged a fee to each amount in which the transaction is split? We will work with Spanish fees (3.4% + 0.35 euros) and in this last case Paypal charges would be significantly higher because of the fixed 0.35 euros that would be charged to each transaction. We are mainly worried about the case this also applies to the commission for the marketplace because we would be loosing money in some transactions when our commission would be lower than 0.35 euros.
This is the only info I've found and I still didn't understand it.
In the text they do not specify that issue (unless I am misunderstanding anything due to I am Spanish-speaking), so I had tried to deduce it with the examples at the end of the text although they pointed that "The scenario above is an example only and is not representative of actual PayPal fees".
But it resulted that the scenarios were completely unreal as they charged a higher fee to a secondary receiver that was receiving an amount of $130 than other receiving $150. So it was impossible for me to get any conclusion.
If the receivers pay the fee, you can specify whether the primary receiver in a payment with several receivers pays the entire fee or all receivers pay a portion of the fee.
•Sender pays the fee – the sender can pay a fee for a simple payment, parallel payment or chained payment.
•Receiver Pays the Fee in a Parallel Payment – the sender can send a payment that is split directly among 2 to 6 receivers. Each receiver pays a portion of the fee based on the amount of the payment each receiver gets.
•Each Receiver Pays the Fee in a Chained Payment – the sender can send a payment that is indirectly split among one or more receivers. The primary receiver, identified as the merchant, pays a fee and each of the other receivers also pay a fee based on the payment amount each receives.
•Primary Receiver Pays the Fee in a Chained Payment - the sender can send a payment that is indirectly split among one or more receivers. If the primary receiver pays the fee in a chained payment, other receivers pay no fees. The fees paid by the primary receiver are based on the total fees assigned to all receivers.
•Secondary Receivers Pay the Fee in a Chained Payment - the sender can send a payment that is indirectly split among one or more receivers. The primary receiver doesn’t have to pay the fees with the secondary receivers paying all the fees.
Fees are determined by PayPal and are based on criteria, such as the transaction volume of the receiver.
So each of your receivers would be charged the (3.4% + 0.35 euros) if you split the payment between the receivers.
Related
I found out Odoo is not creating exchange gains or losses for partial
payments. Only at the time of full payment Odoo is calculating the
exchange difference. This is creating serious headache for the user,
when they see aged payable, receivable, partner ledger, general
ledger, etc exchange rate is not considered. This is giving the users
wrong information about the payments they have made.
Impacted versions: 11
Steps to reproduce:
1) Make 2 different Multi currency Invoices for the single supplier
2) Modify the current exchange rate under currencies
3) Make a partial payment for one single invoice with exchange difference
Current behavior:
It does not generate the Exchange gain or Loss for the partial invoice payments
Expected behavior:
Irrespective of the full payments or partial, it should generate the Exchange gain or Loss as per the payment date and Invoice record Date
By default Odoo will generate exchange gain or loss only when all invoice paid, on partial payments exchange isn't computing.
I have a few bitcoin addresses (and private keys) with small amounts on them (0.001 to 0.01 BTC). Obviously sending them one by one to exchange does not worth their value due to high transaction fee.
Is there a way to aggregate them all into a single address to exchange the total amount then
You don't need an exchange to perform bitcoin to bitcoin transactions. You can send the all small amounts to one bitcoin address using any wallet, and the only fee you are facing will be the miner's fee, which is in your control. You can set a very small fee, or no fee at all - that will simply move your transactions to a lower priority. Wait a few days, and they will be confirmed.
If you want to do it using code, check https://github.com/primal100/pybitcointools
Is there any way to get the exchange rates without fees factored in because they seem to vary based on transaction volume and payment method?
The API documentation says:
Note that exchange rates fluctuates so the price is only correct for
seconds at the time. This buy price includes standard Coinbase fee
(1%) but excludes any other fees including bank fees.
Source: https://developers.coinbase.com/api/v2#get-exchange-rates
So the assumption is you can divide the exchange rate returned by 1.01 to get the fee excluding the standard Coinbase fee of 1% and conversely for sell price, you would multiply by 1.01.
However, the pricing from November 2017 has a much more complex pricing structure and makes no reference to the "standard Coinbase fee" referred to in the documentation.
See https://support.coinbase.com/customer/en/portal/articles/2109597-coinbase-pricing-fees-disclosures
Both an invoice and an users balance can have money added to it?
The invoice has an upper limit of the invoice's price and when filled the invoice is considered paid.
If we had an abstract object be the parent of both the users balance and an invoice what would the abstract object be?
The concrete issue is that I have payments and I have to associate the payments and allocate amounts to either the users balances or invoices.
I thought about Payable, but how do you pay to a balance?
payment->attach(invoice);
payment->attach(userBalance);
//payment object
function attach(WhatInterface whatInterface) {
this->whatInterfaces->add(whatInterface);
}
The problem with object-oriented design is that really there's no answer to your question. Lions, tigers and pussies are all "cats", which are all "animals", but software objects seldom show that sort of intuitively graspable natural hierarchy.
A user's balance is presumably an amount of money, and invoice is a demand for an amount of money. Now you could say invoice "isa" amount of money, or you could say invoice "hasa" amount of money, which is the demand, plus other amounts of money (the VAT, the amount paid, subtotals for the various items).
But there's no right or wrong. It depends on your particular program. I'd guess this is a computer science 101 exercise and your tutor is looking for the answer "accounts".
Let us assume there is a situation when I have an invoice from a supplier to my company (e.g. 1000 EUR). My company returns all the goods because of a problem. The supplier shall issue a credit invoice in amount of 1000 EUR, which I register in my system. As a result I will have (on behalf of the supplier) an account payable of 1000 EUR and an account receivable in the same amount. What is the preferred way of handling this situation, because there will be no money transferred, either way.
Should I generate a paymentApplication to both invoices? I want to see them as +1000 -1000 = 0 EUR.
The current data model and services do not support applying an invoice to an invoice, i.e. canceling part or all of one invoice with another. That is something I have considered but IMO is messy... even if it is a common practice in certain parts of the world (from my limited knowledge of it an archaic practice that isn't so commonly used any more). That could be supported though, I have certainly considered it (adding an entity or perhaps modifying PaymentApplication to support it, adding a service to do it and a corresponding GL posting service to balance AP/AR accounts).
Right now the best thing to do a cancel the original invoice, which does the proper reverse GL postings if the invoice has already been posted.
If you want both invoices in the system and canceling entries somewhere the currently supported approach is to use a FinancialAccount, basically use FinancialAccount payments to pay both invoices and then the balance of the FinancialAccount represents the amount due or owed to the external party. There is full support for these sorts of FinancialAccount transactions, doing payments both ways (withdrawals and deposits), representing the liability for positive balances in the GL, etc.