Refunds

you can refund payments from the payments tab the refund object is a child of the payment object some payment service providers place restrictions on refunds if this is the case, you will need to contact your payment service provider and ask them to enable refunds on your account how it works when a refund is submitted from salesforce, the following flow of events takes place refund request salesforce securely sends the refund request through to the asperato servers asperato identifies the refund requested, the amount requested, and then instructs the card gateway to process the refund against the original transaction depending on the amount, this can either be a full or a partial refund gateway check & refund response on card gateway will (usually) perform some checks on their side—this ensures the refund amount doesn't exceed the value of the original transaction, and sometimes limits the number of individual partial refunds that can be made against the same transaction the card gateway then executes the refund request, and returns the response to asperato refund object & processing asperato will parse the response from the card gateway, and create the relevant refund object in salesforce this will update the "amount refunded" field on the original payment request, if the refund was successful requisites to process a refund, the following must be true on the record the associated payment record should have the status collected from customer in other words, the original payment must have been paid before it can be refunded the record type of the original payment should be inbound required permissions assign the refund permissions to anyone in your organisation that requires it permission set details asperato refund refund read, create, edit legacy compatibility if you are upgrading from asperato v2 19 1 or ealier versions, you must add the picklist value ‘new’ to the refund stage c field on the asp refund c object and mark this value as default ideally it should be at the top of the list so you may need to reorder your values for this picklist you will also need to add the button process refund to the list view layout for the same object and on the refund page the process refund button is in mobile & lightning quick actions create refund records go to the asperato refunds tab click the new button on the action bar a pop up window will ask you to select the payment to refund, refund amount, payment route, and amount click save to finish multiple refunds can be issued against the same payment, so long as your payment provider allows this and the total amount refunded does not exceed the original transaction value process refunds manually on the payments tab, select the payment record and press the refund button a pop up window will ask you to either choose to refund a specified amount up to the original amount of the payment click process refund to finish go to the asperato refunds tab select the refund records to process using the chebox next to them click the process refund button on the action bar you will be asked to confirm the refund processing click yes to finish automate the refund process via scheduled job you can schedule the refund job to process refund records automatically, or even create and process refund records automatically the apex job to process refunds is separate from the existing asperato repeat payments scheduled job it will need to be separate from and scheduled separately scheduling the refund job to process all refund records with a status of ‘new’ can be done in one of the following two ways schedule from within apex classes > schedule apex job name aspertorefundsjob apex class processrefundsschedule select frequency as required if you require the job to run more than once a day, schedule from within developer console using the apex code below (set your own cron expression as per frequency required) string cronexpression ='0 0 ?'; string refundsjob = system schedule('asperato refunds job', cronexpression, new asp04 processrefundsschedule()); system debug(' asperato one repeat payment job scheduled with id ' + refundsjob); via batch class use the following code to create refund records and process them the codes uses map to associate payment ids with refund amounts this approach is designed to create new refund records for specific payments and amounts, and then process those newly created refunds (assuming they meet the criteria of "new" status, correct refund date, and payment status) the refund records will only be picked up with the refund date is today or less, and the payment status is collected from customer map\<id, decimal> paymentidstorefundamountmap = new map\<id, decimal>(); paymentidstorefundamountmap put(payment id, 20); batchsendrefundbypayment refundbatch= new batchsendrefundbypayment(paymentidstorefundamountmap); database executebatch(refundbatch); use this code to process existing refund records the codes takes a list of refund ids this is particularly useful for reprocessing refunds that were in a "failed" status, as long as you provide the ids of those failed refund records—they won’t be picked up automatically using a batch class to process refunds can be done with the following code (the same conditions apply to this as with processing refunds in other ways) failed records can alternatively be submitted via the list view or via the record itself once the reason for failure has been addressed batchsendrefunds refundbatch = new batchsendrefunds(new list\<id> {refundpayment id}); //change the id from list of refund ids database executebatch(refundbatch); refunds with direct debit processing refunds from direct debit payments can be risky a customer is protected under the direct debit scheme rules; if a direct debit is collected in error, they should request a refund from their bank this means you could easily end up with a "double refund", and subsequently have to resort to legal means to claim back the funds