PosiPay v.1.1

URL package: /packaging/installPackage.apexp?p0=04tOZ00000042CvYAI

What’s New

• When creating a Gift Entry via the Manage Gift Entry or Gift Batch process with Payment Method = Credit Card, whether the gift is One-Off or Recurring, a Gift Entry record is created and processed. The Card BIN (first six digits of the card number) will now be stored on the Gift Entry, and a corresponding Payment Instrument will be created with the same Card BIN. All necessary records for the One-Off or Recurring gift are generated accordingly.

• Result Code field length in Gateway Transaction object has been updated from 30 - 100.

• A new invoice External ID is used for linking Gateway Transaction to Gateway Invoice.

  • When processing payments via the Scheduled Donation batch job in PosiPay, and assuming webhooks are properly configured, the system uses a parsed invoice ID as the External Invoice ID on the Gateway Invoice and as the Transaction Reference ID on the Gateway Transaction to establish a link between the two. This applies to both Credit Card and BECS/Direct Debit payments—whether successful (real-time or delayed) or failed. In all cases, multiple Gateway Event records are generated, and all existing field mappings remain in place. The Gateway Transaction is linked to the corresponding Gateway Invoice using this matching logic, and care must be taken to ensure no duplicate records are created throughout the process.

  • A new External Invoice ID is now used to link Gateway Transaction records to Gateway Invoice records during the Scheduled Donation batch job process. Whether the payment is a Credit Card or BECS/Direct Debit, and whether it is successful (real-time or delayed) or failed, the following flow occurs (assuming webhooks are properly configured): multiple Gateway Event records are created; a Gateway Invoice is created with External Invoice ID = parsed invoice ID; and a Gateway Transaction is created with Transaction Reference ID = parsed invoice ID. Both the Gateway Invoice and Gateway Transaction records are linked to each other as well as to the corresponding Gift Transaction record—bidirectionally. All existing field mappings remain in place throughout. In delayed BECS payments, records are updated after processing. It is essential to ensure that no duplicate records are created at any point in the process.

• Email and Amount fields can now be hidden from the Stripe Form. The Stripe Payment Form now supports dynamic visibility and editability of the Amount (including currency) and Email fields based on configuration. For the Amount field: if the Amount attribute is not empty, the field is shown or hidden based on the Hide Amount setting, and set to read-only or editable based on the Read-only Amount flag.
  If the Amount attribute is empty, the field is always displayed regardless of the hide flag. For the Email field: if the Payment Method is Credit Card, visibility is controlled by the Hide Email flag. If the method is BECS Debit or Direct Debit, and the Email Address attribute is not empty, visibility follows the Hide Email setting; if the attribute is empty, the field is always displayed. These same rules apply when tokenising payment details via the Stripe customer form. This provides more flexibility in tailoring the form to specific use cases.