Only one mandate per account: mandate stored as an account custom field instead of on the payment method

Abierto
  • ¿Algo no está bien?
#45 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
backend, database, payments

Línea de trabajo

Start in src/main/java/org/killbill/billing/plugin/gocardless/GoCardlessPaymentPluginApi.java: addPaymentMethod writes the account custom field near L340 and getMandateId reads it back at L141. Copy the table shape from a sibling plugin's DDL under src/main/resources, add gocardless_payment_methods/gocardless_responses keyed on kb_payment_method_id, resolve the mandate from kbPaymentMethodId in purchasePayment, and implement getPaymentMethods/getPaymentMethodDetail/deletePaymentMethod/resetPaymentMethods. Done when a second payment method keeps its own mandate and existing GOCARDLESS_MANDATE_ID custom fields migrate onto the account's default method.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

The GoCardless mandate is stored as a single account-level custom field named GOCARDLESS_MANDATE_ID, rather than being associated with the Kill Bill payment method.

Written in addPaymentMethod:

https://github.com/killbill/killbill-gocardless-plugin/blob/main/src/main/java/org/killbill/billing/plugin/gocardless/GoCardlessPaymentPluginApi.java#L340-L342

Read back in getMandateId, which returns the first match and stops:

https://github.com/killbill/killbill-gocardless-plugin/blob/main/src/main/java/org/killbill/billing/plugin/gocardless/GoCardlessPaymentPluginApi.java#L141-L152

Consequences

  1. One mandate per Kill Bill account, permanently. Adding a second payment method attempts to add a second custom field with the same name on the same account, which CustomFieldApiExceptions — so the second mandate cannot be stored at all.
  2. kbPaymentMethodId is ignored on the payment path. purchasePayment resolves the mandate from kbAccountId, never from the payment method it was actually asked to charge. If an account somehow ended up with two payment methods, both would charge the same mandate.
  3. No multi-scheme support. A customer cannot hold, say, a BACS mandate and a SEPA mandate, which is a normal requirement for a business collecting across the UK and the EU.
  4. deletePaymentMethod is a no-op, so the custom field outlives the payment method and the account is left permanently pinned to a stale mandate.
  5. getPaymentMethods always returns an empty list and getPaymentMethodDetail returns an empty GoCardlessPaymentMethodPlugin, so the mandate is invisible to KAUI and to the API.
  6. No plugin tables. Unlike the other Kill Bill payment plugins, there is no gocardless_payment_methods / gocardless_responses schema, so there is nowhere natural to put this.

Proposed work

Adopt the standard killbill-plugin-framework-java shape used by the Stripe/Adyen/Braintree plugins:

  1. Add DDL for gocardless_payment_methods and gocardless_responses (plus _transactions if useful), keyed on kb_payment_method_id.
  2. Store the mandate id, scheme, customer id and bank account summary on the payment method row, not on the account.
  3. Resolve the mandate from kbPaymentMethodId in purchasePayment, not from kbAccountId.
  4. Implement getPaymentMethods / getPaymentMethodDetail / deletePaymentMethod / resetPaymentMethods against those tables.
  5. Provide a migration for existing installs that moves GOCARDLESS_MANDATE_ID custom fields onto the account's default payment method.

Item 5 matters — the custom field is the current production storage, so this cannot be a clean break.

Lenguaje dominante
Java
Estrellas
4
Forks
7
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de killbill/killbill-gocardless-plugin

Todos los issues de killbill/killbill-gocardless-plugin

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.