v2.2 php -> Shopeepay payment method returns 'something is missing' and URL not found, even if our URL callback is still alive

Question

v2.2 php -> Shopeepay payment method returns 'something is missing' and URL not found, even if our URL callback is still alive

firmanserdana opened this issue 2 years ago · 16 comments

firmanserdana commented 2 years ago

All other payment methods are okay, but then when we use Shopeepay, the FE side gets this notification

it was fine until 2 days ago, tracing it, it seems we get expired status, from the shopeepay endpoint

midtrans and our side are okay though

should updating the dependency solve the issue, if not, why we don't get any notification if 2.2 is deprecated?

the CS team was just asking log charge, like what is that? even asking our source code, which not helpful at all 😢

well thanks for any help

Answer 1 · 2022-10-17T04:15:02.000Z

HI @firmanserdana so the issue in here you not receive the http notification right?

I checked for this order id S221015111054 and yes the http notif expired failed to sent because url not found.
I can reproduce the error (404 in Midtrans notification worker, we use this header User-Agent:Veritrans and somehow your endpoint return 404 to us. that’s why notification history says URL not found.

So please check your endpoint.

make sure that the Notification URL can be reached from Public Internet. Midtrans cannot send notifications to localhost, URL protected with authorization or password, URL behind VPN, unusual destination port, and so on. You may also need to make sure the following IP address is not blocked from your infrastructure. If you just want to make sure the notification is authentic, you can implement Verifying Notification Authenticity section below.
https://docs.midtrans.com/en/after-payment/http-notification?id=https-notification-webhooks-of-payment-status

Answer 2 · 2022-10-17T04:24:13.000Z

Yes but the problem is on shopee side, seems like we miss something, because other payment method works

Normally we would be able to open the shopee app using the deeplink

But sure, we are gonna check it first from our side

Thank you

Answer 3 · 2022-10-17T09:48:06.000Z

HI @firmanserdana so the issue in here you not receive the http notification right?

I checked for this order id S221015111054 and yes the http notif expired failed to sent because url not found. I can reproduce the error (404 in Midtrans notification worker, we use this header User-Agent:Veritrans and somehow your endpoint return 404 to us. that’s why notification history says URL not found.

So please check your endpoint.

make sure that the Notification URL can be reached from Public Internet. Midtrans cannot send notifications to localhost, URL protected with authorization or password, URL behind VPN, unusual destination port, and so on. You may also need to make sure the following IP address is not blocked from your infrastructure. If you just want to make sure the notification is authentic, you can implement Verifying Notification Authenticity section below. https://docs.midtrans.com/en/after-payment/http-notification?id=https-notification-webhooks-of-payment-status

The possible problem is in the other endpoint for getting the deep-link url for shopee payment.
the url is on the first image, do midtrans change the url or might be add some parameter to get the shopee deeplink ?

Answer 4 · 2022-10-17T09:55:51.000Z

Hi,
Could you clarify what action you do on FE when get that error?
Looks like you try to call the redirect_url shopeepay from FE/BE. Which is unexpected.

The steps to integrate with ShopeePay are given below.

Send the Charge API request to Midtrans.
Open the redirect url in the response to get redirected to Shopee app.
Handle the redirect from Shopee app back to merchant app.
Handle notifications

So you just need open the redirect_url shopeepay. Here is the complete docs https://api-docs.midtrans.com/#shopeepay

Answer 5 · 2022-10-17T10:01:48.000Z

More likely our backend tryin to do http request on this link

"actions": [
        {
            "name": "deeplink-redirect",
            "method": "GET",
            "url": "https://wsa.uat.wallet.airpay.co.id/universal-link/wallet/pay?deep_and_deferred=1&token=dFhkbmR1bTBIamhW5n7WPz2OrczCvb8_XiHliB9nROFMVByjtwKMAl6G0Ax0cMr79M4hwjs"
        }
    ]

since shopeepay doesnt return the deeplink redirect like gopay did so our backend trying to scrap the link from that URL response. but unfortunately the request give 404.

Answer 6 · 2022-10-17T10:03:27.000Z

if u see on the gojek charge resonse it did have the app deeplink but not on shopee.

{
            "name": "deeplink-redirect",
            "method": "GET",
            "url": "gojek://gopay/merchanttransfer?tref=1509110800474199656LMVO&amount=10000&activity=GP:RR&callback_url=someapps://callback?order_id=SAMPLE-ORDER-ID-01"
        },

Answer 7 · 2022-10-17T10:06:53.000Z

i do double check the link directly on the mobile phone the link is already works as a deeplink,

so it kinda solve our problem now

Answer 8 · 2022-10-17T10:11:22.000Z

Yes correct, the link should be open via mobile phone.
Thanks

Answer 9 · 2022-10-17T10:26:33.000Z

is that possible to get the direct deeplink with shopee/

like the one on gopay response? so it doesnt hv tobe redirected to browser first?

Answer 10 · 2022-10-17T10:45:51.000Z

Is not possible, the charge response will be contain ShopeePay universal link.

Also currently on Gopay charge response we give response with universal link too.

Answer 11 · 2022-10-17T10:53:08.000Z

@Andrenzo17 since when the changes (universal deeplink) are applied?

Can us be notified again in the future if there is a change, even if it's a minor change? Such small change could break our ecosystem

Answer 12 · 2022-10-17T11:30:36.000Z

The Gopay Universal Link Changes starting on 23 August 2022.
AFAIK, we already info all merchant about the changes Gopay Universal link via email.

Answer 13 · 2022-10-17T11:34:28.000Z

What about the shopee ones?

Answer 14 · 2022-10-17T16:40:43.000Z

I still found the gopay payment is still using the direct link with gojek/ prefix.

Answer 15 · 2022-10-18T01:57:37.000Z

What about the shopee ones?

Midtrans did not perform any changes for Shopeepay recently, it was always been Universal Link instead of Deeplink.
I think the issue happen because changes on Shopeepay side, which Midtrans is not informed either.

since shopeepay doesnt return the deeplink redirect like gopay did so our backend trying to scrap the link from that URL response. but unfortunately the request give 404.

Midtrans never recommend that kind of flow, Universal Link should be provided directly to redirect customer, not being fetched internally on Merchant side. Hence it is not the scope of Midtrans if that flow does not work any longer.
Your method seems to be working before Shopeepay change it on their side.
Maybe Shopeepay now implement anti-bot protection for their universal link, which may return 404 if your request detected as bot.

so it doesnt hv tobe redirected to browser first?

Universal link have better compatibility compared to deeplink. In case customer have not install the app, they’ll be taken to the app store to install. Which helps with conversion rate.
Why does universal link take user to browser first, it highly depends on each of platform (Android, iOS) device behavior, which is external factor that not under our control.
However the modern best practice is: Universal Link, instead of Deeplink.

I still found the gopay payment is still using the direct link with gojek/ prefix.

Screenshot you attach above is universal link.
Previously API response from Midtrans is gojek:// deeeplink and since 23 August 2022 we replace with new https://gojek.link/ universal link.

Answer 16 · 2022-10-21T04:22:59.000Z

No response from the author, If any general questions, please contact us here

Thank you