refund/void/credit (and auth/capture) are unimplemented stubs that silently return CANCELED

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
33/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
payments

Línea de trabajo

Stubs live in src/main/java/org/killbill/billing/plugin/gocardless/GoCardlessPaymentPluginApi.java (authorize L72, capture L82, void L219, credit L230, refund L241). Read purchasePayment first to see how the GoCardless payment id is stored (first payment reference plus paymentId plugin property); refund and credit then use the pinned SDK's RefundService, void the pending_submission cancel action. authorize/capture should raise PaymentPluginApiException rather than return CANCELED. See #43 for asynchronous refund state and the existing tests for expectations.

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

Descripción

Problem

Five of the seven PaymentPluginApi transaction methods are stubs. They ignore their arguments, never call GoCardless, and unconditionally return PaymentPluginStatus.CANCELED:

Method Line
authorizePayment L72
capturePayment L82
voidPayment L219
creditPayment L230
refundPayment L241

Only purchasePayment talks to the gateway.

Why this matters

Refunds are the significant gap. GoCardless supports refunds against a collected payment (POST /refunds), and the pinned SDK already exposes RefundService. Today a refund issued in Kill Bill silently reports CANCELED while no money moves — the operator gets no error telling them the operation was not performed, and Kill Bill and GoCardless diverge. Any real deployment needs refunds.

Credit maps naturally onto the same RefundService, or onto a payout depending on the semantics wanted.

Void has no meaningful equivalent once a collection is submitted, but a GoCardless payment in pending_submission can be cancelled (POST /payments/:id/actions/cancel), which is the closest analogue and is worth wiring up.

Auth/capture genuinely does not exist in bank debit schemes — there is no authorization hold. These two should stay unimplemented, but should say so explicitly.

Proposed work

  1. Implement refundPayment against RefundService, resolving the GoCardless payment id from the transaction (it is already stored — purchasePayment writes it as the first payment reference and as a paymentId plugin property).
  2. Implement creditPayment, deciding explicitly whether it maps to a refund or a payout.
  3. Implement voidPayment as a payment cancellation, valid only while the payment has not yet been submitted; return a clean error otherwise.
  4. For authorizePayment / capturePayment, throw PaymentPluginApiException stating the operation is not supported by bank debit schemes, rather than silently returning CANCELED.

Point 4 applies to all of them: a stub that reports CANCELED is indistinguishable from a genuine gateway-side cancellation. Unsupported operations should be loud.

Note that refund state is asynchronous too, so this overlaps with #43 — a refund is not final when the API call returns.

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.