Best Practices to Implement Payments With Salesforce Billing

Set up and thoroughly test your Gateway integration in a Salesforce Sandbox. Note that Payment Gateway sandboxes are not necessarily exact reproductions of production. Please work with your Payment Gateway to set up features in a sandbox to match your intended production setup. This may involve enabling tokenization and setting up special features to match what is used in production. Make sure that all payment types that you plan to use are supported by the Gateway and the Integration. This could include Credit Cards, ACH, Debit Cards, and pre-authorizations. 

If you are planning to use one of the Self-Service Payment Pages, make sure the payment gateway integration you are using is compatible with this set up. The integrations provided by Salesforce Billing are all compatible. See the Gateway Type section in our Processing Payments with Payment Gateways article for more information.

Payment Runs, created by a Payment Scheduler, can potentially create a large number of records. After testing in a sandbox, we suggest that you first test small payment runs in production to confirm that the setup was migrated correctly. Use the Payment Batch field on the Invoice to control the number of invoices in a batch. Note that when the Payment Scheduler has null in the Payment Batch field, it selects all qualifying Invoices for payment, regardless of the Payment Batch field. In other words, all batches are selected.

Reconcile your payment transaction records in Salesforce against your Payment Gateway regularly to confirm that they match. We suggest doing this at least one time per payment run to catch errors early and make corrections before the next run. If you use the Payment Center or Guest Payments, then reconcile at least one time per day.

Payment Runs create Payment Transaction records that should match the transactions in the Gateway. Successful Payment Transaction records create Payment records that are then Allocated to the relevant Invoices. Any user that creates a payment scheduler must have all the permissions as outlined in this document since the payment run that was created is an apex job that runs in the context of the user that created it. 

Missing permissions could allow payments to be created in the gateway without creating or updating the relevant records in Salesforce leading to missing payment records and, possibly, duplicate payments from future payment runs.

Understand the impact of having a roll-up summary field for Payments on the Account. During a Payment Run, Payments are created which update the roll-up summary field on the Account record and possibly trigger other automation. With this set up, Payment Runs should be run at a time when no other Apex Jobs are running that update Accounts. A row lock error that occurs on the Account could prevent the creation of a Payment record. If this happens, an Error Log is created. The Payment record will need to be created and Allocated to the Invoice before the next Payment Run or a duplicate payment is possible.  

If you are migrating payment methods from another package, test to make sure the migrated data works in both a Payment Center and a Payment Run. Make sure to test payments and refunds. Note that in addition to the gateway token, a refund requires card number (last 4), card expiration month and year, and card type. If this information is not available dummy values must be used for card number, expiration month and year, and card type to successfully process a refund.

Salesforce Billing triggers help to enforce PCI Compliance by making sure that CVV and full Credit Card Number are not stored when creating a payment method. Only the last four digits of the Credit Card number are stored. Disabling the Billing triggers might be needed when migrating a large number of records, creating payment methods with a custom process, or under other circumstances specific to your org. When doing so, make sure not to store the CVV and only store the last 4 numbers of the Credit Card Number.

Naming convention for Payment Schedulers. Choose a name that readily identifies the Apex Job as a Payment Run to make it easy to find under Setup > Scheduled Jobs in case you have to Cancel Upcoming Payment Runs.

• For example: Naming it as PAY Batch 1 Weekly distinguishes this from an Invoice Run and other Payment Runs.

Dashboard Components or Reports are an excellent way to quickly see what has been created and if any payments or associated records require attention. Here are a few suggestions:

• Unallocated Payments
• Successful Payment Transactions without a Payment record
• Invoices with Corrective Action (Payment Run) = Action Required and the InvoiceLocked field = TRUE