In the 5.12.0 release, we added "context" to the payment data, both in shortcode and block checkout.
However, we did not add any methods that plugins could use to determine the context easily.
This PR adds a few helper methods to the gateway class to determine the current processing context.
Details
We did have a SV_WC_Payment_Gateway::is_block_checkout() method, which used a POST value that we were using while developing 5.12.0. However, at some point we changed the POST data, and forgot to update to work with the new context field.
I renamed the existing SV_WC_Payment_Gateway::is_block_checkout() method, because it's only used in one plugin, which hasn't been released yet.
I used the term "processing context" because "payment context" could easily be confused with the PaymentContext passed to Gateway_Checkout_Block_Integration::prepare_payment_data(). Also, "checkout context" did not seem precise enough, because "checkout" can either refer to the checkout page or the action of checking out.
Summary
In the 5.12.0 release, we added "context" to the payment data, both in shortcode and block checkout. However, we did not add any methods that plugins could use to determine the context easily.
This PR adds a few helper methods to the gateway class to determine the current processing context.
Details
We did have a
SV_WC_Payment_Gateway::is_block_checkout()method, which used a POST value that we were using while developing 5.12.0. However, at some point we changed the POST data, and forgot to update to work with the new context field.I renamed the existing
SV_WC_Payment_Gateway::is_block_checkout()method, because it's only used in one plugin, which hasn't been released yet.I used the term "processing context" because "payment context" could easily be confused with the
PaymentContextpassed toGateway_Checkout_Block_Integration::prepare_payment_data(). Also, "checkout context" did not seem precise enough, because "checkout" can either refer to the checkout page or the action of checking out.