Recording How The Refund Was Paid

outline a sales credit on its own says what was returned, not how the customer was made whole to keep your brightpearl accounts reconciled, refundid also creates customer payments against the credit showing where the money came from how the refund is allocated the allocation depends on the resolution the customer chose store credit the full credit value is recorded against your store credit payment method no money left your bank, and brightpearl reflects that instant refunds the full credit value is recorded against a dedicated refundid payment method refundid funded the refund up front, so this keeps it separate from your own takings and makes the later refundid invoice easy to reconcile against standard refunds the credit is allocated back across the payment methods the customer originally paid with, in order the original card or online payment is used first, up to the amount actually taken through it, and anything left over is allocated to store credit up to the amount originally paid that way that ordering matters on split payment orders a customer who paid part card and part store credit is credited back in the same shape, rather than the whole refund landing on one method refunds larger than the original payments if a standard refund comes to more than the customer originally paid through those methods which usually points to a data problem rather than a genuine refund the integration stops and raises an integration error rather than guessing your team is then prompted to check the return before anything is posted if you would prefer the unallocated remainder to be booked to a catch all payment method instead of stopping, let us know during setup and we'll configure it that way multiple payments on one credit each allocation is created as its own customer payment, so a split refund shows as two payment lines against the credit rather than one blended amount every payment carries a unique transaction reference built from the rma reference, the return id and the credit, which prevents the same refund being recorded twice if a request is retried what you need to provide during setup we need the exact payment method codes configured in your brightpearl account for your normal online payment method store credit the refundid payment method used for instant refunds these have to match brightpearl exactly, so the payments post against the right accounts