I have the ability to allow my clients to pay with SagePay. Currently, my pricing structure with SagePay means that I get hit with a large % fee if my clients pay using a credit card; for this reason, I always ask them to pay with a debit card, or agree to an additional % fee for using a credit card. Until now, this has been simple: I take payments over the phone, and can see if they are trying to use a credit card and apply the fee myself.
With QuickFile invoices, however, I cannot do this. I could ask SagePay to remove the ability to pay with a credit card, but I’d rather not do this as some clients don’t have another payment card and don’t mind the charges.
Speaking to SagePay, it seems that with the latest version of their integration, Protocol V 3.0, there is the option to pass on surcharges by card/currency type. SagePay have checked on my behalf and said that you are using V 2.2.3. My question is, do you have any plans to integrate this ability into your system? It would make life much easier for people such as myself!
I think the SagePay API will only solve a part of the problem, if the fee is automatically applied within SagePay there needs to be some way to update the invoice record on Quick File, to reflect the additional surcharge. I think a better approach would be to apply the fee to the invoice and then redirect to SagePay, that way we can use the same function for all payment gateways rather than rely on specific logic just for handling SagePay payments and then having to do something similar for Worldpay, PayPal, Stripe etc.
For now I’ve converted this thread to a feature. Others wishing to add their vote can do so.
Whatever works is fine by me. All I would say is that there has to be an option to apply the surcharge based on the selected card type. I don’t get charged a fee for debit cards (well, nothing that I want to pass on), only for credit cards. If the surcharge were applied directly to the invoice before passing to the gateway, how would quickfile know which card type is being used?
Sorry I didn’t realise you were selectively applying a surcharge depending on what card type is selected. In this case it would definitely need to be handled using the SagePay API.
Hi @Glenn, yep that’s right. Under the new protocol, it’s possible to define surcharges according to payment type/currency. I would like to pass on surcharges for credit cards, but not for debit cards.
I still think you’re right, though, that this extra amount has to appear somewhere in the accounts. Perhaps it could appear as a new invoice/payment for the client? Just thinking out loud.
I certainly hope it’s something that you can do! As it stands, I’ve had to disable all credit cards on my SagePay account to avoid the possibility that someone will pay with one and cost me a fortune.
+1 from me. I have just started using stripe for my card processing, but am currently only enabling it when customers agree to pay a surcharge. I have suggested this in the past, so hopefully something can be implemented for those who wish to pass on the credit card fees. Paypal also have prohibitivley expensive processing fees.
Don’t Stripe and PayPal levy the same charges on credit and debit cards (both as a percentage)? With SagePay and Worldpay they usually have a flat fee for debit cards and a percentage for credit cards. For this reason we’d need two quite different approaches to solve this problem I think.
With SagePay, I was given the option of either having the same % fee on all cards, or a flat rate for debit cards and a % for credit cards. I chose the latter.
With the differential pricing for SagePay, any surcharges would not be known by you until the payment has come back, since you wouldn’t know which card is being used in advance. Therefore, when you get the payment back and you see there’s been an over-payment, the surcharge could then be listed as another payment from the client, and an appropriate invoice created to match it. When they log in to see their invoices, they would then see an additional invoice detailing this charge.
For the case of systems where the surcharge isn’t applied at the payment end, I suppose you could still just notify the client that a surcharge is being applied, and then do the same thing: create a new payment and invoice to match.
Stripe charge a flat 2.4% +20p per successful credit card transaction. Not sure if that is applicable for debit cards as they say they accept them, then don’t include them in the specific list in their help. I thought debit cards were supposed to attract lower processing fees?. Paypal charge a top rate of 3.4% +20p and then it is tiered downwards depending on monthly processing amounts, so I guess it will be difficult to get data from Paypal to know what charges to add.
Either way, I’d like to start offering card payments to my customers, and many do ask and are surprised that I don’t, especially being an IT company - but I can’t absorb the card fees and need a way of automating the surcharge before offering it to all my customers.
@ueslondonltd I’m not 100% sure here but if an amount comes back from SagePay that exceeds the invoice amount the difference may just get allocated as a credit to the client account, which can then be applied to an invoice alter. I would need to check with my colleague on that. If this is the case it may solve your problem. Anything that involves automatically modifying the invoice to account for the difference will be very fiddly on our side and something we’re not likely going to have time for in the near future.
Applying a charge before the client goes into the payment portal is also possible but again it’s not something that we can implement quickly I’m afraid. Still we’re exploring the ideas here which is always the first step.
I just wanted to bump this up. It would be fantastic if it were possible to add selective surcharges (for credit cards). It would make life much easier, and it’s something that seems to be built into many other systems without problem!
Hi, I would like to charge my customers the 2% or so that gocardless and stripe charge when using their services, but when setup with those payment options my customers don’t get charged anything, and there is no option to charge them. I would disable all payment options and get them to phone through but its then a case of modifying the invoices to add card percentages which then makes it a lot of hard work. Any ideas?
It’s not something we’re looking at right now, realistically it will be looked at in Q4 of 2014. I’ll update this thread when we are able to explore this further.
I just want to float something here to see what people think:
One way we can implement this without too much trouble is to allow a percentage or fixed amount to be configured for each payment processor. For example on PayPal I might want to apply a 2.5% premium to every payment made against a single invoice or multiple invoices. When the end user client reaches the payment screen if a surcharge is being added we can highlight it under that specific payment option.
When the client completes the payment any additional surcharge above the invoice will simply be allocated as a surplus client credit. This is crucial to keeping it simple as anything involving adding additional item lines to invoices will be much more complex, especially when there are multiple invoices involved.
It’s not perfect as it involves manually adjusting things later. On the plus side it is relatively simple to add and could be the first step to something more sophisticated.
Thanks for updating us on this. It would still be an incredibly useful feature. We’re even speaking to software developers to create a system for us just to implement it.
Your suggestion makes sense, but the problem for us is that the surcharge should be based on card type, not payment processor, as we get charged for credit cards only. As I mentioned before, the latest SagePay API does allow the adding of surcharges based on card type. If you implemented it at that stage, you would still get an overpayment coming back as credit to the client, which would be fine by us - we could simply raise an invoice to cover it.
I guess for those payment providers that charge a simple % fee on all payments, your suggestion would be great. But we wouldn’t be able to use it!
