Allow charging a transaction fee for credit card payments

Ideas & feature requests
1

We previously have used another software to take payments and it provided credit card processing for a fee as well as EFT or Electronic Funds Transfers for a much smaller fee. We will not offer credit card transactions due to the fees involved but EFT’s tend to run about .25% or some just charge a flat fee. Please offer this option. I really hope there aren’t any ties with Stripe to be exclusive because that would be a huge road block for us.

At the very least, offer a button to add on a 3% credit card transaction fee.

1 Like
Forward on Stripe merchant fees to customer
2

Thanks for the suggestion.

We’ve already got a thread for direct debit payments at Support for direct debit payments managed by Breww via Stripe which is worth a vote if you’re looking for this. We’ve no lock-in or exclusivity deal with Stripe, but we will be introducing this via Stripe initially as we’ve already done lots of work with them, making the dev work required to add this feature via Stripe much less than via another payment provider. We’re happy to also look at other providers if you’d like to suggest someone.

I’ve edited this thread to be specifically for adding a transaction fee for credit card payments, as we need threads to have one specific feature in them in order for them to pick up on votes. Cheers.

3

Are there any enhancement plans to “Allow charging a credit card transaction fee” - (ideally the BREWW user could set the % cc fees) for customers that want to pay via credit card - like a 3% fee? This was originally suggested by Andrew Wlodarczk in 2023.

I feel this would be a great option to the BREWW-STRIPE integration and appreciate your consideration.

1 Like
Stripe card payments integration is now live! - Trade store payments & refunds (and more coming soon)
4

Thanks, Kerry. I’ve moved your post to the applicable feature request.

This feature request doesn’t currently have any votes, and votes are an important part of our prioritisation process. If you can add a vote to this, it will help us better prioritise it. For more on how we handle feature requests, please see 💡 Posting ideas & feature requests for Breww 💙

5

I support this as a feature too!

Unfortunately Stripe doesn’t offer the option for customers to pay CC fees directly.

1 Like
6

Adding a vote here! We can’t move into Breww/Stripe until we have this fee. Unfortunately, that 3% really starts to add up on the wholesale side.

2 Likes
8

Realizing that it is relatively complicated to sort out what is sent to STRIPE (or other payment integrations) from Breww and back to accounting, the full integration of dynamic credit card charges may be challenging and keep being postponed.

Minimally, there are some relatively easy programmatic changes that could perhaps be made that would go a long way towards improving the surcharge issue with online payments.

These are some suggestions that would make a difference and may not be as challenging to implement in Breww sooner rather than later:

  1. Move the ‘Allow Online Payments’ from the general invoice settings to the individual invoice type settings under Invoicing Details. Assuming a company has different invoices set up for Services, and Wholesale orders, this would mean, for example, that Services Invoices (using a specific invoice type) could be set to NOT allow Online Payments (because services invoices could easily be over $10,000) while Wholesale Invoices could be set to use Online Payment.

  2. Set a limit for Online Payments, either in the general Invoice Settings or in the Invoicing Details settings. For example, online payments may be allowed for an order under a user set ‘xxx.xx’ amount and not allowed for orders that exceed that amount.

  3. Establish a fixed tag (or flag) at the customer level that would override the invoice setting for a customer to make online payments.

None of these three options above really solve the surcharge issue, they just contain it to potentially eligible transactions and amounts, which does go a very long way towards making online payments more useful to Breww customers.

  1. Some other thoughts on a surcharge implementation are: Given that the issue is mainly about getting a dynamically imposed surcharge back to Brew and into an accounting system while maintaining a match to invoice values is challenging, another approach might be worth looking at to solve the issue.

If a dynamically determined surcharge was created in STRIPE the original invoice payment could flow back to Breww and the surcharge could either flow back to Breww as an additional related value or flow from STRIPE to another tracking account, or be ignored by Breww if the user has not set up a specific surcharge tracking account.

For example,

a) The Breww user would set up the a surcharge amount for credit cards and debits in the general invoice settings and check a box that they understand that they want surcharges used and that this is legal in their regulatory jurisdiction (thus removing the liability of surcharges from Breww Ltd).

b) The Breww user would select the accountancy account that surcharges would flow to.

c) The Breww user enable online payments as per items #1,2 & 3 above

d) Breww would pass the parameters to STRIPE to allow or disallow dynamic surcharges and to what account the surcharge information should go. If Breww could (ideally) get the surcharge information returned from STRIPE, it could be recorded in Breww and sent to accounting from Breww. If Breww cannot get the information back from STRIPE, could STRIPE could pass it along as a separate amount to the provided accounting account, along with the invoice number and customer information, so that accounting will still reconcile even if Breww does not have visibility into the dynamic surcharge that was paid?

Item 4) above would potentially realize the full surcharge functionality but with a lot more work then items 1 - 3. These updates could be rolled out separately and the simpler solutions of items 1-3 would probably be about 20% of the work for 80% of the value of the full solution.

Hope this helps to get a surcharge solution going.

Cheers!

9

Thanks for all the ideas, Ian.

Firstly, we don’t like the concept of building a few pretty obscure features as a temporary workaround for the lack of the real feature, so that’s not the route we would like to take.

We are, however, much more interested in solving the real problem.

The dynamic fee amount isn’t actually too hard… It’s impossible. We cannot tell Stripe to charge (for example) $100 + card processing fees. We have to give them the final amount. It would also be quite unfair to the paying customer not to actually know how much they are agreeing to pay. The only option here is for breweries to specify a single flat rate fee for card payments. For example, you could specify 3% card fee, and you could pitch this at a fair rate based on your own payment processing fee agreements with Stripe. Most businesses already have a “blended rate” for card fees from Stripe, which makes this much easier for them (though I appreciate that the blended rate doesn’t cover all possible card types).

The hard part, which is partly why we haven’t tackled this yet, is: what if the invoice is already finalised? Typcially a customer will pay after the invoice has been raised. At this point, we prevent changes to the invoice in Breww, so we cannot change the amount without a fair bit of complication, not to mention confusion for your own accounts team and your customer’s finance department.

Even if we built a solution to this in Breww (and ignored that it would make it impossible to trust “invoiced” figures not to change retrospectively), we would still face the problem of accounting platforms such as QuickBooks & Xero. Some of the platforms we integrate with support changing invoice values after upload (although we don’t support this in Breww at this time), while others don’t. Some only support it conditionally, and I’m quite confident that this would become a complete mess in no time :anguished_face:

My proposal to solve the sticking point here in a way that fits in the existing Breww structure and would be compatible with all our accounting platforms would be to raise a “supplementary” invoice for the additional card fee. This would only need to happen if the order being paid had been invoiced, if not, we could adjust it before invoicing to add the fee. If we do need to raise the supplementary invoice, you might have INV-001 for $100 of product and then INV-002 for $3 of “Card processing fees relating to INV-001”. They would get their own invoice number (next available, not necessarily consecutive) and be an invoice in their own right, but clearly reference back to the original.

This would also be a reusable concept to assist with Allow charging invoice late fees which is also blocked on the same blocker.

Does this sound workable for you? Or do you have any other ideas for solving this part of the blocker?

10

Luke - Even though this wasn’t addressed to me, I’ll pipe in here since I’ve been following this thread closely.

For our business, we would only move to accept credit card payments for wholesale invoices if we can seamlessly add on the 3% processing fee. As an aside, one solution I am considering is building this cost into our base pricing and offering a discount for ACH, Check or Cash payments.

From what I can gather the solution you present (a second invoice) just complicates the experience for the customer. If I’ve learned anything in this role its that we want to make the experience of buying our product as seamless and satisfying as possible. Any hassle or extra hurdle will just push customers towards another brand that doesn’t make their life more complicated.

Lastly, if I put myself in the shoes of a customer who receives two invoices for one order, I am not only put off by the hassle, it seems a less scrupulous individual could easily just ignore the “fees” invoice as “optional”. Our customers already seem to think late fees even when included in the same invoice, are optional.

It is a shame that Stripe and/or Quickbooks don’t just make this option available for businesses to choose who pays the CC fees.

11

Thanks, Tait, we’d love the feedback and thoughts of as many people as possible - it should help us to get to the best final solution.

I agree that two invoices isn’t ideal, but I’m struggling to find an alternative solution (if anyone has one, please put it forward).

  • There would only be two invoices if the original order has been invoiced already (at the point of payment). If it hasn’t we could attach the charge to the original invoice.
  • Your customer can’t really treat the second invoice as optional, as it would already be paid. I think this is somewhat different from the risk of them ignoring a “late fees” invoice. The process would be:
    • You raise an invoice for $100 of product.
    • Customer opts to pay by card with a 3% fee.
    • Customer pays you $103 in a single payment, with the amount clear and up-front.
    • The supplementary invoice for $3 is raised and marked as paid by the same $103 payment.

At Breww, for our own accounts, we use Xero, and most of our invoices go through a platform called Dext to help us manage our invoices. As most invoices arrive by email, we forward them on receipt to Dext (by email), and they make their way to our Xero account. We later pay the invoice, and if at this point we were reissued the same invoice number but for a different amount (say it now includes a card fee), this would be ignored by Dext as a duplicate that it had already processed. The finance team would then struggle to reconcile the payment to the invoice, as it wouldn’t match. However, if we were to receive another invoice for the card fee, this would make its way to Xero (via Dext), and the payment would match the combined total of the invoices, and there would be no confusion on the finance/accounts team side of things.

I agree this isn’t perfect, but I don’t think a perfect solution exists (when the payment is made after the invoice was raised). We would love to hear the thoughts and ideas of anyone who can contribute to this and may have better ideas than I’ve managed to come up with. Opinions on whether the supplementary invoice approach would be workable for you (even if not perfect) would be great too.

12

Thanks Luke - maybe I misunderstood the end user experience.

If the customer only needs to make one transaction (for $103 in the example) then this would work better than I am imagining.

1 Like
13

@ian-binmore @andrew-wlodarczyk @david-birnbaum @kerry-kopp - could we please have your thoughts on whether the above implementation idea would work for you here (a supplementary fees invoice is raised (and paid in the same payment) if the main order has already been invoiced)? Thank you.

14

Hi Luke,

Thanks for taking a look at this. The experience you are describing would work fine, from my perspective. It mirrors what I have seen in other platforms, although with those, the additional charge being raised by the accounting platform (since that what was driving the payment process).

Both Xero and Quickbooks have the option to do the second fee as a Sales Receipt (QB) or a Receive Money (Xero) since they are not technically invoices. That is how our current system handles it, but it’s a minor annoyance because you have to manually match two (or more) transactions to a single bank receipt line. That would be a new type of sync for you, and I don’t think you have an equivalent artifact for a fee on your side.

It would be important for the sync to the accounting software to make it easy, if possible, to link the bank transaction to the two items cleanly. Assuming you are doing this with two invoices In Xero, this would mean creating a batch payment linking them together. If so, that would be great.

Last thought - I don’t know how Stripe deposits batches into a bank account. If it does a single deposit for all Credit Card and ACH transactions, then doing the bank rec is going to become potentially very painful (ACH payments will clear three days later than the credit card payments, which means a batch will contain a variety of payment dates). If it’s at all possible to create the matching entry corresponding to the actual monetary transfer, that will save a lot of agony (and having to download the settlement detail from Stripe and clicking through to line them all up!

David.

1 Like
15

Hello Luke,

Thank you for working on this and asking for more input!

I think that the proposal would generally work, with a few further considerations.

  • We really do not want to send a second invoice just for for fees because we feel it would have very poor customer optics.
  • Could your idea of a 2nd invoice be executed as an option to send a second invoice immediately, or to save a fee to be added to the account for the next full invoice sent?
    • This provides us with an opportunity to add the fee to the Next Invoice on that account, effectively providing the same result as a second invoice, but with arguably better optics.
    • If a company thinks the customer is not a repeat customer, they could still send out the second invoice.
  • The concern for us with globally enabling online payments is that our expensive Services invoices (usually over $5k) would have a 3% fee. To mitigate this we added at ‘Invoice Details/Services Invoice’ under Bank Details that says: “a 3% convenience fee will be applied to your account”. This already works with the idea of a fee that can be 2nd invoiced or added to an account for ‘next invoice’

Other items to improve the implementation

  • Adding an ‘adjustment’ option to the invoice adjustments that makes the credit card adjustment simpler and consistent would help when a C.C. fee is added.
    • From ‘Add Adjustment’ there could be an additional option to add a ‘Credit Card Convenience Fee’. The rate (ex. 3%) would ideally be established at either the global invoice setting or at the invoice details setting level and would be automatically calculated when selected.
  • The ‘accept online payments’ setting is currently global at the ‘Order/Invoice Settings’ level. If this could get moved to the ‘Invoicing Details’ level it would help a lot as we would have much better control over who could pay online, based on the invoice template they get.

Hope this helps!

Cheers, Ian

1 Like
16

Hey Luke,

I just completed a transaction with one of our Vendors (Lagersmith.com) - They use a platform called Zoey.com and integrate with Stripe to process payments on their portal and have a seamless and clear ability to choose payment method and if choosing credit card add a 3% processing fee. No complications. Maybe this will help lead towards a solution?

1 Like
17

Thanks everyone for your comments on this and I’m sorry for not getting back to you before.

There’s a lot of good information here. We’re going to give this some thought on how best to handle and follow up here if we have any further questions.