--- title: GoCardless Actions & User Actions slug: payments/gocardless-actions-and-user-actions description: Learn to use GoCardless actions and user actions in Unaric Payments to automate workflows and control what users can do with payment records in Salesforce. docTags: createdAt: 2025-02-23T18:29:22.178Z --- ## GoCardless actions The following diagrams describe how each GoCardless action interacts with Unaric Payments records. These diagrams show status changes, GoCardless events, and additional field changes. ::::Tabs :::Tab{title="Payments"} ```mermaid 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
asp04_Payout_Reference__c = payout
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
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 ``` ::: :::Tab{title="Authorisations"} ```mermaid 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 ``` ::: :::Tab{title="Refunds"} ```mermaid 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 ::::Tabs :::Tab{title="Cancel Mandate"} - 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 *** ::: :::Tab{title="View Mandate"} - 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 *** ::: :::: ::::Tabs :::Tab{title="Process Authorisation"} - Button location: Record Page Button - Primary action: Set up Authorisation via MOTO route (agent-led from Salesforce) - Process flow: 1. Opens PayPage in new tab 2. Salesforce user enters member's payment details 3. Processes via MOTO route 4. Fields populated after PayPage submission via "Update Authorisation" button - Field updates: 1. Status - Possible Values: Pending, In Force, Failed (depending on outcome) 2. Payor Details Section - Name (from PayPage) - Email (from PayPage) - Billing Address Fields (from PayPage) 3. Payment Route Selected - Direct Debit or Card (based on chosen method) 4. System-Generated Tokens - Asperato Repeat Token (auto-generated when processed) - Payment Service Provider Repeat Token (auto-generated when processed) 5. Account Information - Mandate Reference (for Direct Debit only) - Account Reference - Bank Name (if Direct Debit) - Account Name 6. Card Information (if applicable) - Card Type - Expiry Date *** ::: :::Tab{title="Payment Using Authorisation"} - Button location: Record Page Button - Primary action: Create new Payment against In Force Authorisation - Process flow: 1. Opens popup screen 2. Allows amount entry for collection 3. Creates new Payment record 4. Automatically populates Authorisation lookup 5. 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 ::::Tabs :::Tab{title="Process Payment using Authorisation"} - 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 *** ::: :::Tab{title="Process Payment"} - 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: 1. Opens PayPage in new tab 2. Salesforce user enters member's payment details 3. Processes via MOTO route 4. Fields populated after PayPage submission via "Pay with Card/Direct Debit" button - Field updates: 1. Payment status & description - Status updates based on PSP outcome 2. Payor details Section - Name (from PayPage) - Email (from PayPage) - Billing Address Fields (from PayPage) 3. Payment route selected - Direct Debit or Card (based on method chosen) 4. Reference numbers - Unaric Payments Reference (auto-generated) - Payment Service Provider Reference (auto-generated) - Account Reference 5. Payment method details - For Direct Debit: - Bank Name - Account Name - For Card: - Card Type - Expiry Date 6. Additional fields - Source: Set to "Repeat" *** ::: :::: ::::Tabs :::Tab{title="Refund"} - Button location: Record Page Button - Primary action: Initiate a Refund from Salesforce - Process flow: 1. Opens popup screen 2. Requests Refund Amount 3. Creates Refund record 4. 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 *** ::: :::Tab{title="Cancel Payment"} - 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** :::hint{type="info"} 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: 1. Refund Status - Possible Values: - Refunded to customer - Failed 2. 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