Outbound Payments

asperato supports making outbound payments to vendors directly through salesforce how it works asperato uses an airwallex wallet to pay vendors directly from within salesforce airwallex supports payment processing to over 123 countries in 36 currencies outbound payments work within salesforce native user interface, employing distinct record types for the asperato payment and authorisation objects and allowing automation options beneficiary bank details are securely stored, validated, and tokenized within salesforce flow enable outbound payments outbound payments are disabled by default and require meeting certain prerequisites and having an airwallex account to enable them, start by getting in touch with asperato support for more information about the process, see enable outbound payments docid\ koo4s9aviu7f nqwvqrdn create outbound authorisation outbound authorisations enable payments to suppliers by storing and verifying their bank details authorisations must be submitted for verification to the psp and authenticated via email by the user before becoming in force and eligible for use create a payment record outbound payments can be created manually in asperato or automatically through certinia's accounting vendor payments approval and processing once approved, the payment moves to awaiting submission and enters processing sending and verification when processed, the payment is submitted if it is sent successfully, additional checks determine if the payment later expires or is rejected final outcome if sending fails, the system retries until the payment is successfully sent or all attempts are exhausted (resulting in a failed status) you also have the option to cancel the payment, moving it to cancelled flowchart graph td a\["create outbound authorisation"] > b\["submit authorisation for verification"]; b > c\["authentication email sent"]; c > d\["user clicks email to authenticate"]; d > e{details valid?}; e yes > f\["authorisation in force (sent to airwallex)"]; e no > g\["authorisation failed"]; f > h\["create payment record"]; h > i\["pending for approval"]; i > j\["awaiting submission"]; j > k\["processing"]; k > l{payment sent?}; l yes > m\["payment sent"]; l no > n\["retry in progress"]; n > o\["payment resubmitted"]; o > l; l no > p{retry attempts exhausted?}; p yes > q\["failed"]; p no > n; classdef startend fill #002d4c,stroke\ none,color #fff,font weight 400,font family\ helvetica,rx 5px,ry 5px; classdef process fill #42a4dd,stroke\ none,color #fff,font weight 400,font family\ helvetica,rx 5px,ry 5px; classdef decision fill #f4f7fa,stroke\ none,color #002d4c,font weight 400,font family\ helvetica,rx 5px,ry 5px; class a,d,f,g,h,i,k,o,r,t,v startend; class b,m,p,q process; class c,j,n,s,u decision;