judgej
commented
8 years ago Note from Sage Pay: whether surcharges are going to be supported internally to the API, and if so, when, is not yet decided. What happens will depend on other priorities and on customer demand for this feature.
Making a big assumption, I suspect surcharges will be handled very differently.
With Sage Pay Server, the rules for adding surcharges, based on which payment type the user chooses, is sent to Sage Pay so that the calculation can be done there. The merchant site has no idea what card is used, and so what the final charge is, until the result of the transaction comes back. It is likely to differ from the base charge if surcharges are used.
Now, with Pi (Sage Pay Integration) the merchant site gets to know what payment type was chosen before the transaction for a payment or authorisation is made. So the surcharges can now be handled entirely on the merchant site. This can even go to the extent that JavaScript on the payment form can be used to present the surcharge to the user before the payment is submitted, so the user has a change to back out or choose another payment method.
So given that, why would Sage Pay Pi need to handle surcharges at all? I don't think they will (but I will ask).
A method in this package to register surcharges and match against card types would be handy. Or maybe just leave it up to the payment wrapper package to implement that? Any thoughts? I'm going to sleep on it. Remember, this package handles the data, the messages, and a certain amount of the logic, but how that is put together into a user flow is for a wrapper package or plugin to take care of, because there are just too many different ways this API may be used.