Payment Service Providers
GoCardless
Actions & User Actions
gocardless actions the following diagrams describe how each gocardless action interacts with asperato records these diagrams show asperato status changes, gocardless events, and additional asperato field changes graph td a\[start] > b(created) b awaiting submission > c(submitted for collection) c confirmed > d(collected from customer) c cancelled > e(cancelled) c failed > f(failed) d paid out > g(paid out) g > g comment{asp04 payout date c = arrival date\<br/>asp04 payout reference c = payout\<br/>asp04 payment stage description c = this payment has been paid out by gocardless} d charged back > h(charged back) h > h comment{asp04 payment stage description c = this charged back payment has been paid out by gocardless} h charged back > g f successor enabled > i{retry max 3 times then stay in failed} i yes > j(retry in progress) j > j comment{asp04 attempt retry c = true\<br/>asp04 next retry date c = data given by gc for next retry} j > f %% node styles style a fill #08496b,stroke #1b7ea1,color #fff style b fill #08496b,stroke #1b7ea1,color #fff style c fill #1b7ea1,stroke #08496b,color #fff style d fill #08496b,stroke #1b7ea1,color #fff style e fill #1b7ea1,stroke #08496b,color #fff style f fill #08496b,stroke #1b7ea1,color #fff style g fill #1b7ea1,stroke #08496b,color #fff style h fill #08496b,stroke #1b7ea1,color #fff style i fill #1b7ea1,stroke #08496b,color #fff style j fill #08496b,stroke #1b7ea1,color #fff %% comment node styles style g comment fill #ffffff,stroke #1b7ea1,stroke width 2px,color #08496b style h comment fill #ffffff,stroke #1b7ea1,stroke width 2px,color #08496b style j comment fill #ffffff,stroke #1b7ea1,stroke width 2px,color #08496b %% brace styles for comment shapes style g comment shape\ braces style h comment shape\ braces style j comment shape\ braces graph lr a\[start] > b(awaiting submission) b active/transferred/created > c(in force) c cancelled > d(cancelled) c failed/expired > e(failed) %% node styles style a fill #08496b,stroke #1b7ea1,color #fff style b fill #1b7ea1,stroke #08496b,color #fff style c fill #08496b,stroke #1b7ea1,color #fff style d fill #1b7ea1,stroke #08496b,color #fff style e fill #08496b,stroke #1b7ea1,color #fff graph lr a\[start] > b(new) b paid > c(refunded to customer) b failed > d(failed) %% node styles style a fill #08496b,stroke #1b7ea1,color #fff style b fill #1b7ea1,stroke #08496b,color #fff style c fill #08496b,stroke #1b7ea1,color #fff style d fill #1b7ea1,stroke #08496b,color #fff gocardless user actions following is a description of what each of gocardless buttons for each object do and what fields they update authorisation object button location record page button primary action cancel gocardless mandate from within salesforce field updates field status new value cancelled technical implementation makes call to gocardless via webhooks cancels mandate within gocardless and bank restrictions only applicable for direct debit authorisations will show error if used on card authorisation button location record page button primary action view gocardless mandate from within salesforce field updates none display behaviour opens a new screen shows direct debit mandate shows direct debit guarantee restrictions only applicable for direct debit authorisations will show error if used on card authorisation button location record page button primary action set up authorisation via moto route (agent led from salesforce) process flow opens paypage in new tab salesforce user enters member's payment details processes via moto route fields populated after paypage submission via "update authorisation" button field updates status possible values pending, in force, failed (depending on outcome) payor details section name (from paypage) email (from paypage) billing address fields (from paypage) payment route selected direct debit or card (based on chosen method) system generated tokens asperato repeat token (auto generated when processed) payment service provider repeat token (auto generated when processed) account information mandate reference (for direct debit only) account reference bank name (if direct debit) account name card information (if applicable) card type expiry date button location record page button primary action create new payment against in force authorisation process flow opens popup screen allows amount entry for collection creates new payment record automatically populates authorisation lookup submits to payment service provider for processing field updates none in authorisation object requirements authorisation must be in force purpose immediate payment processing payment (list view) object process payment now object type payment button location list view primary action send bulk payments immediately to psp field updates field payment status possible new values submitted for collection collected from customer failed (depending on psp outcome) requirements payment must be in "awaiting submission" status must have authorisation lookup populated limitations maximum 200 payments at a time (salesforce limits) purpose bulk processing of multiple payments without waiting for scheduled apex job payment object button location record page button primary action send payment immediately to psp for processing field updates field payment stage possible new values submitted for collection collected from customer failed (depending on psp outcome) requirements payment must be in "awaiting submission" status must have authorisation lookup populated purpose immediate processing without waiting for scheduled apex job button location record page button can create link to show moto paypage in other record/screen flow primary action submit payment via moto route (agent led from salesforce) process flow opens paypage in new tab salesforce user enters member's payment details processes via moto route fields populated after paypage submission via "pay with card/direct debit" button field updates payment status & description status updates based on psp outcome payor details section name (from paypage) email (from paypage) billing address fields (from paypage) payment route selected direct debit or card (based on method chosen) reference numbers asperato reference (auto generated) payment service provider reference (auto generated) account reference payment method details for direct debit bank name account name for card card type expiry date additional fields source set to "repeat" button location record page button primary action initiate a refund from salesforce process flow opens popup screen requests refund amount creates refund record sends to payment service provider for processing field updates field total refunded new value value of refund record recommendations only recommended for card payments not recommended for direct debit purpose initiate refund processing directly from salesforce object type payment button location record page button primary action cancel payment sent to gocardless but not yet collected field updates field payment stage new value cancelled restrictions only applicable for payment method "direct debit" payment method "open banking" payment status must be "submitted for collection" refund object process refund not required for refunds created through "refund" button on payment record (these process automatically) object type refund button location record page button primary action process refund records created manually field updates refund status possible values refunded to customer failed refund status description success message error message if failed use cases when refund record created manually from "new" button on refund list view when created via a flow and refund processing not initiated through flow or list view