Authorisations

authorisations represent saved payment methods that can be used for future transactions they are essentially records of customer payment information (or supplier bank details for outbound payments) stored securely and used to authorise payments key concepts secure storage of payment methods sensitive payment details (credit card numbers, bank account information) are never stored directly in salesforce instead, they are tokenized by psps, ensuring compliance with pci dss standards only the secure tokens are stored in salesforce flexible processing options authorisations can be initiated and processed in two ways agent assisted (internal) your sales or support team can collect payment information from customers over the phone or through other channels and enter it into salesforce using a secure payment page customer self service (external) a unique, secure link is generated and sent to the customer they can then use this link to enter their payment information directly through a hosted payment page automated recurring billing once a customer authorises a payment method, it can be used to automate recurring payments for subscriptions, instalments, or other recurring charges status updates the status of each authorisation is tracked within salesforce you can see at a glance whether an authorisation is active ("in force"), pending, cancelled, or has failed custom references you can optionally add custom references to authorisations for internal tracking, reporting, or reconciliation purposes in this way, you can link authorisations to specific orders, invoices, or other records in salesforce outbound payment capabilities (for suppliers) although less common, authorisations can also be used to store supplier bank details for processing outbound payments payment processing the in force authorisation can be used to initiate a payment this typically involves using the asperato system to create a payment record in salesforce and linking it to the relevant authorisation asperato then uses the tokenized payment details stored in the authorisation to process the payment through the chosen payment gateway (e g , stripe, gocardless) updating and managing authorisations the authorisation record can be updated if necessary (e g , if the customer changes their payment details) it can also be cancelled or expired, which will prevent further payments from being processed how it works create an authorisation record this record will initially contain information about the customer (or supplier, for outbound authorisations) and the intended payment method (e g , card, direct debit) crucially, at this stage, no actual payment details are entered an authorisation can be created for any payment route aside from paypal processing the authorisation the actual payment information is collected and processed there are two ways to collect this information internally (agent assisted) or externally (customer self service) for outbound authorisations, you can submit for verification the account details before moving forward in force status once an authorisation is created and successfully processed (reaching the "in force" status), it's ready to be used for its intended purpose what happens next depends on whether it's an inbound or outbound authorisation for inbound, the in force status is used to receive payments from customers, often automatically and repeatedly for outbound, it's used to send payments to suppliers, usually as individual transactions asperato maintains these records with any state changes that you need to be aware of for example, if your customer cancels a direct debit, asperato will update the appropriate authorisation to a cancelled state within salesforce acting on these state changes is something you can do via salesforce customers payment confirmation or failure the payment gateway returns a confirmation or failure message this information is updated in the payment record in salesforce flow flowchart td classdef startend fill #002d4c,stroke\ none,color #fff,font weight 600,font family\ helvetica,rx 5px,ry 5px; classdef process fill #42a4dd,stroke\ none,color #fff,font weight 500,font family\ helvetica,rx 5px,ry 5px; classdef decision fill #f4f7fa,stroke\ none,color #002d4c,font weight 600,font family\ helvetica,rx 5px,ry 5px; a\[create authorisation record in salesforce] >b{process authorisation?} b internally (agent) >c\[click 'process authorisation' button] c >d\[paypage appears —internal—] d >e\[customer/agent enters payment details] e >f\[authorisation details updated in salesforce] b externally (customer) >g\[retrieve 'ecommerce url'] g >h\[send url to customer] h >i\[customer clicks url] i >j\[paypage appears —external—] j >k\[customer enters payment details] k >f f >l{authorisation successful?} l yes >m\[authorisation status in force] l no >n\[authorisation status failed] m >o\[use authorisation for payment] n >p\[investigate and resolve issue] class a,m,o,n,p startend class c,e,f,g,h,i,j,k process class b,l decision key fields field description authorisation url this is the link you provide to your customers to enable them to provide authority to save a payment method status tells you if the authorisation is ready to use or not authorisations have to be ‘in force’ before they can be used to collect payments status description a descriptive text showing the reason related to the current status might contain the reason for cancellation or failure for example payment route options (required) allows you to choose which authorisation routes are available to your customer to use e g card, direct debit or ach payment route selected tells you which type of payment method has been granted by the customer statuses in order for an authorisation to be used to collect payments, it must be marked as status of in force the following statuses are available on the authorisation object status description awaiting submission the authorisation has not yet been processed through a payment service provider pending this status is used for direct debits, and indicates the authorisation has been processed but is not yet in force direct debit authorisations have a lead time of a few days before they become active see timing cycles https //gocardless com/direct debit/timings/ for details this status isn’t relevant for card authorisations, as they become active (or fail) instantly in force the authorisation has been confirmed, is valid, and can be used to authorise a payment submitted for cancellation status value introduced in package version 2 16 this status is used for direct debit payments created using gocardless connection it shows that the mandate/authorisation has been submitted for cancellation at the request of the payor, or at your request the status is automatically updated to cancelled when the mandate is cancelled at gocardless cancelled the authorisation has been cancelled at the request of the payor, or at your request failed the authorisation is not valid / no longer valid and cannot be used to take payments expired the authorisation has expired, and can no longer be used to take payments