- v1.0.0-latest-prod
Add the ability to archive existing payments as part of the create payment request. This is meant to simplify the requests that the frontend must make when the customer chooses to declare a different payment method, esp. after their initial payment method’s checkout transaction failed. See CreatePaymentRequest#shouldArchiveExistingPayments & CreatePaymentRequest#gatewayTypesToArchive.
Fixed an issue when the 3DS/HPP callback token cannot be validated because the failed payment is archived, & that failed result was already recorded/applied via the webhook, before the callback endpoint is engaged.
Improvements to support the Adyen payment integration
Added an ability to send the additional data in the TransactionExecutionRequest, needed to execute payment transactions, esp. properties that should not be persisted to the Payment#paymentMethodProperties
Introduced the ability to pass line item data to PaymentTransactionServices as part of the TransactionExecutionRequest for all transaction types.
Enhanced the data passed via the PaymentInfo object to payment gateway resources, including the owning entity id & initial transaction amount data.
Introduced plumbing to update the payment gateway’s representation of a payment, along with a request to update the PaymentTransactionServices payment. Note: this also includes providing the gateway’s update response as part of the PaymentTransactionServices endpoint response.
Introduced logic allowing updates of supplemental payment data (e.g. the billing address) without requiring that the payment is cloned and archived.
Updated DefaultPaymentAccessValidationService logic to potentially allow updating a payment if only supplemental data is provided (thus not changing the underlying payment method, initial transaction amount, etc.) while the payment has the CUSTOMER_MUTABILITY_BLOCKED_FOR_PAYMENT_FINALIZATION access restriction.
Introduced the broadleaf.paymenttransaction.service.allow-supplementary-updates-while-mutability-blocked-for-payment-finalization property declaring whether updating supplemental data is allowed in this state.
Introduced plumbing around PaymentGatewayTransactionService#identifyTransactionReferenceIdOverrideForInitialTransaction to support custom logic for declaring the transactionReferenceId for an initial checkout transaction.
Introduced plumbing around PaymentGatewayPaymentSummaryService#buildNextActionFromPayment for building a PaymentSummary#nextAction based on payment data, rather than transaction data. Note: this is meant to be used if the payment does not yet have any transaction data.
Updated payment update endpoints to ensure that the payment id provided as a path variable aligns with the payment id in the request payload.
Addressed backwards and forwards compatibility for Spring Boot 3.1.x and 3.2.x.
Updated the extensibility of JpaPayment, JpaPaymentTransaction, and JpaSavedPaymentMethod by formatting them in line with other calls to the getManagedType() method.