Refund management

[hasanzade-hasan]

Refunds can be initiated by using Refunds API.

You can either do partial or full refunds.

{
  "transaction_id": "f3ba29ea-5644-4e4b-aacd-8d854ebb3d46"
  "amount": 5.00 (optional)
}

[hasanzade-hasan]

@gadimbaylisahil As far as I can see, refund API request is not dependent on specific payment method, it is just transaction_id? So single place for all payment methods will do the job. Is this right approach?

[hasanzade-hasan]

@gadimbaylisahil What properties of refund we should store in DB? Asking to see whether we need migration for this or can be handled using custom fields?

[hasanzade-hasan]

@gadimbaylisahil Can admin cancel refund?

[hasanzade-hasan]

@gadimbaylisahil Is there webhook processing for refund status updating?

[gadimbaylisahil]

YES.

[gadimbaylisahil]

You may like to store, refund_id returned from BP API.

[gadimbaylisahil]

@gadimbaylisahil Can admin cancel refund?

NO.

[gadimbaylisahil]

@gadimbaylisahil Is there webhook processing for refund status updating?

Webhook can be received mentioning the transaction status refunded. However, when making refunds using shopware, you willl receive the refund response instantly, so you will do the transition from paid --> refunded.

However, in case merchant tries to refund in Better Payment dashboard(outside shopware) and then send a webhook, plugin should make the transition.

However, I think the second part is already the case(with your webhook handler)

[gadimbaylisahil]

Temporarily, we can use rest/transactions/:transaction_id/log endpoint to retrieve all the events happened on the transactions.

Here, we would care about the event that has the type as refund.

You can use it to display in the appropriate view in Shopware, including amounts.

Example response:

[
  {
    "created_at": "2023-02-15T23:09:38.591+01:00",
    "type": "initialization",
    "status": 1,
    "amount": 0,
    "execution_date": null,
    "message": null
  },
  {
    "created_at": "2023-02-15T23:10:03.225+01:00",
    "type": "payment",
    "status": 3,
    "amount": 6.5,
    "execution_date": null,
    "message": "Request successfully processed in 'Merchant in Connector Test Mode' (000.100.112)"
  },
  {
    "created_at": "2023-02-15T23:10:03.470+01:00",
    "type": "fee_calculation",
    "status": 3,
    "amount": 6.5,
    "execution_date": null,
    "message": null
  },
  {
    "created_at": "2023-02-15T23:10:03.563+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-15T23:20:02.563+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-15T23:30:01.582+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-15T23:40:01.760+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-15T23:50:01.679+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-16T00:00:02.657+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-16T00:10:02.542+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-16T00:20:01.591+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-16T00:30:01.685+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-16T00:40:01.597+01:00",
    "type": "postback",
    "status": 4,
    "amount": 0,
    "execution_date": null,
    "message": "Transaction 224 postback raised Curl::Err::SSLPeerCertificateError: "
  },
  {
    "created_at": "2023-02-20T11:14:26.016+01:00",
    "type": "refund",
    "status": 7,
    "amount": 6.5,
    "execution_date": null,
    "message": "Request successfully processed in 'Merchant in Connector Test Mode' (000.100.112)"
  },
  {
    "created_at": "2023-02-20T11:14:26.266+01:00",
    "type": "fee_calculation",
    "status": 7,
    "amount": 6.5,
    "execution_date": null,
    "message": null
  }
]

[gadimbaylisahil]

We should also investigate if out of the BP refunds can happen in Shopware.(like cash refunds, or a refund that merchant decides to do outside our systems, like wire transfer etc...)

This can happen with a payment method that does not support refunds natively.

[hasanzade-hasan]

• [x] Turn on allow different payment method after checkout failure
• [x] Only display refund section for paid and partially_paid transactions.
• [x] Do not show refund card if transaction is not made with BP API.
• [x] When clicked on refund, if response is successful, render list of refunds, and let user know that it’s correctly executed. In case of failure, display failure notification.

[hasanzade-hasan]

@gadimbaylisahil In GET rest/transactions/TRANSACTION_ID endpoint I got also CORS error.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://devapi.betterpayment.de/rest/transactions/039c4158-6ba5-407d-8bce-96b254e8e140. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

This endpoint is used to determine whether refund is full or partial.