Gateways / payment methods input fields API #154
Comments
|
Sounds like a good enhancement. First thoughts:
|
It might be useful to register unsupported payment methods. In the UI we can inform users about unsupported payment methods.
Good point, maybe this is a better approach? // ...
$gateway->can_process_payment( $payment );
// ...
class Gateway {
// ...
public function can_process_payment( Payment $payment ) {
$method = $payment->get_method();
// check if method is supported?
// check if method is active at payment provider?
// check if amount is sufficient?
// check country / currency / etc.
}
}
Yes, i agree. A gateway integration could extend the default iDEAL issuer field: class IDealIssuerField extends CoreIDealIssuerField {
public function __construct( $gateway ) {
$this->gateway = $gateway;
}
public function get_options() {
// Request iDEAL issuer via `$gateway`?
}
}Thats requires gateway integrations to register their own iDEAL issuer field. We could also transform the core iDEAL issuers options to the gateway / provider corresponding iDEAL issuer value. Downside of that is that we no longer have a dynamic iDEAL issuers list that is updated automatically. Or we could implement a callback in the $this->register_payment_method( new PaymentMethodIDeal( $callback = function() use( $gateway ) {
// Request iDEAL issuer via `$gateway`?
} ) ); |
👍
Yes,
That seems the best approach to me. Loosing the dynamic lists is not an option. |
$this->register_payment_method( new PaymentMethod( 'ideal', 'iDEAL', $supported = true, $active = true, $fields = array( Fields::get( 'ideal-issueur' ) ) ) );For some gateways the iDEAL bank / issuer is required to start a payment, other gateways will ask customers to choose the bank / issuer in their environment. Therefore it is probably not useful to reuse the iDEAL issuer field over different gateways. $ideal_issuer_field = new IDealIsseurField();
$ideal_issuer_field->set_required( true );
$payment_method_ideal = new PaymentMethod( 'ideal', 'iDEAL' );
$payment_method_ideal->set_supported( true );
$payment_method_ideal->add_field( $ideal_issuer_field );https://www.digiwallet.nl/nl/documentation/paymethods/directdebit#startapi $iban_field = new IBANField();
$iban_field->set_required( true );
$name_field = new NameField();
$name_field->set_required( true );
$payment_method_direct_debit = new PaymentMethod( 'direct_debit', 'Direct Debit' );
$payment_method_direct_debit->set_supported( true );
$payment_method_direct_debit->add_field( $iban_field );
$payment_method_direct_debit->add_field( $name_field );In WooCommerce we can change this to something like: $payment_method = $gateway->get_payment_method( $this->payment_method );
$fields = $payment_method->get_fields();In the test meta box we can iterate over all the available payment methods. foreach ( $gateway->get_payment_methods() as $payment_method ) {
foreach ( $payment_method->get_fields() as $field ) {
// render field
}
}With some JavaScript / AlpineJS magic we can show only the fields for the selected payment method. For forms plugins like Gravity Forms it's harder to make sure we retrieve all the required input. |
|
Related issue/PR, which would benefit from improved payment method registration: |
|
Currently we have the following fields: Gender:
Date of birth:
Consumer bank details name:
Consumer bank details IBAN:
Issuer iDEAL
Issuer credit card
|
|
I removed the
To-do:
|
|
We should not forget that |
|
|
In Not all supported extensions have support for We need a way to flat |
|
In pronamic/wp-pay-core@f21d102 we removed the phone number field from the test meta box. We have to figure out how we handle checkout fields like a phone number. Payment methods like AfterPay.nl often also require a complete shipping and billing address. Perhaps we should extend the test meta box to a full-fledged checkout form such as WooCommerce. For example, for the AfterPay.nl payment method, we may have to indicate that the fields 'shipping address' and 'billing address' are required, but leave the display and handling of these fields to the extensions. Also see: |
|
I think discussed before my holiday with @rvdsteege, but could not find any information about this. We could add a
That allows us to 'query' for example only the payment methods with the status $payment_methods = $gateway->get_payment_methods( [
'status' => 'active',
] );$payment_methods = $gateway->get_payment_methods( [
'status' => 'active',
'cache_results' => false,
] );Something similar might also come in handy within the fields: $fields = $payment_method->get_fields( [
'class' => IdealIssuerField::class,
] ); |
Found it in https://github.com/pronamic/wp-pronamic-pay-private/issues/8. |
|
For next week we have still a few things to-do:
|
We stick to term |
|
For the iDEAL issuer this is currently handled in: We should no longer use the In Restrict Content Pro: $payment->post_data = $gateway->subscription_data['post_data'];in core: $payment->post_data = $_POST;also in core: Plugin::process_payment_post_data( $payment ) {
$gateway = $payment->get_gateway();
if ( null === $gateway ) {
return;
}
$payment_method = $gateway->get_payment_method( $payment->get_payment_method() );
if ( null === $payment_method ) {
return;
}
foreach ( $payment_method->get_fields() as $field ) {
if ( array_key_exists( $field->get_id(), $payment->post_data ) ) {
// ?
}
}
} |
|
I think we are done, the items from #154 (comment) are included on following issue: |
Some gateways and payment methods require extra input from the customer. For example: iDEAL payment method requires sometimes an iDEAL issuer / bank and AfterPay often requires a birth date and gender. In this core library we have support for input fields. There is however room for improvement so we can write code more according to the DRY principle. Some gateways / payment methods require the same input. In our internal Basecamp project we also have a to-do open to this:
I think we need a global place where can define 'checkout fields'. In this core library we can define the most common used 'checkout fields' like:
Also see:
https://github.com/woocommerce/woocommerce/blob/4.7.0/includes/class-wc-checkout.php#L197-L281
https://github.com/woocommerce/woocommerce/blob/4.7.0/includes/abstracts/abstract-wc-payment-gateway.php#L392-L405
For each gateway / payment method we must be able to indicate what input is required. As soon as an extension does not provide the required data, we can show an intermediate screen in which the missing data is requested. Similar to how, for example, OmniKassa 2.0 does this:
We might need to extend the way we define which payment methods are supported by the gateways in
get_supported_payment_methods():That way we can also only show the input fields in the test meta box that are required for the chosen payment method.
This requires some thought.
The text was updated successfully, but these errors were encountered: