Recurring Payment from ARB

109 Views Asked by At

I would like to test the webhook on Recurring Payment (Not when setup, but when the transaction is made, ie: 1 months time).

Is it safe to assume that the event type is net.authorize.payment.authcapture.created.

If this is the case it seems like no actual useful data is sent from Authorize, its just internal data. They do not seem to send the profile ID or anything, is this the case?

        {
            "notificationId": "10760e7d-afce-4f95-9772-43ada4f19cee",
            "eventType": "net.authorize.payment.authcapture.created",
            "eventDate": "2023-12-15T03:27:29.344375Z",
            "webhookId": "bedfdb50-f7c7-49f6-8ebb-b593ca776164",
            "payload": {
                "responseCode": 21,
                "authCode": "572",
                "avsResponse": "M",
                "authAmount": 12.5,
                "entityName": "transaction",
                "id": "245"
            }
        }

Any advice on how to fully test a payment coming from recurring and how you guys actually link this to your DB data (user_id) I was going to store the user profile and use that to link but user profile is not returned on the callback, so maybe I need to take the TX ID and run that threw a call to get TX information ?

Thanks.

1

There are 1 best solutions below

0
On

It seems to be like below, yet I can not find any documentation in regards to this:

(Both support on EMAIL and support on CHAT deny this and tell me its not true, but the stack over flow links posted below say it is ....)

{
    "notificationId": "c453f527-8b7c-407d-8ec7-b022188af4a7",
    "eventType": "net.authorize.payment.authcapture.created",
    "eventDate": "2021-05-08T17:51:20.5783303Z",
    "webhookId": "3b2fd08b-a7c4-4f29-95b5-8330958d6031",
    "payload": {
        "responseCode": 1,
        "authCode": "OT3UUE",
        "avsResponse": "Y",
        "authAmount": 1.00,
        "entityName": "transaction",
        "id": "60167299547",
        "subscriptionId": "1234567890"
    }
}

In the internal callback (from acceptUI/acceptJS) you can store the subscription ID in a DB, then you can get the user_id for what user you need to credit/ship to by looking it up in the DB with the "subscription ID" reference.

The documentation only contains the tx id and not sub id, so if this is the case user would need to call the endpoint to get the transaction details to get the sub id.

Reference:

ARB test in subscription and webhook notification case

Webhook Notification With Authorize.Net

https://community.developer.cybersource.com/t5/Integration-and-Testing/ARB-Subscription-webhooks-not-working/td-p/63173 (Even though support staff told me NO ! it looks like on their own forums they say yes....)