GoCardless Actions & User Actions
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.
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
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: 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
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
- 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