search

allegro / allegro-api

Issue tracker and wiki for Allegro REST API
https://developer.allegro.pl/
212 stars 39 forks source link

[NEWS] Mapowanie paymentId i transactionId oraz filtorwanie po payment.id i surcharges.id #1878

Open MartaNowaczyk opened 5 years ago

MartaNowaczyk commented 5 years ago

Udostępniliśmy metodę GET /payments/payment-id-mappings, dzięki któremu możesz uzyskać paymentId podając wartość transactionId lub odwrotnie. Wystarczy wpisać w zapytaniu wartości dla jednego z dwóch parametrów:

Przykładowy request:

  'https://api.allegro.pl/payments/payment-id-mappings?paymentId=21f96ba2-714f-11e9-a1f2-5b017850bf22'
  -H 'Authorization: Bearer'
  -H 'accept: application/vnd.allegro.public.v1+json'

Przykładowy response:

{
    "paymentId": "21f96ba2-714f-11e9-a1f2-5b017850bf22",
    "transactionId": "1012284437"
}

Zasób zwraca powiązania dla transakcji złożonych w ciągu ostatnich trzech miesięcy.

Poz tym w zamówieniach udostępniliśmy możliwość filtrowania zamówień po:

lkowol commented 5 years ago

Przy odpytaniu o stare transactionId, nie posiadające mapowania, zwracacie 500 z komunikatem "An error has occurred", bez szczegółowych informacji. To samo, jeśli płatność nie istnieje.

Dla paymentId działa dobrze.

Maczuga commented 5 years ago

Potwierdzam powyższy komentarz, aczkolwiek w moim przypadku błąd wyskoczył przy odpytaniu jednego z transactionId z dzisiaj. Inne 2 z tego dnia przeszły bez problemu.

Na 859 transactionId (od 1 lutego do dzisiaj), 157 zwróciło błąd. Data raczej nie ma na to wpływu, ponieważ mam niektóre ID z lutego, które przechodzą, oraz takie z czerwca, które nie przechodzą.

PawelTaberski commented 5 years ago

@lkowol , @Maczuga Podeślijcie proszę przez formularz kontaktowy transactionId, które nie przechodzą wraz z informacją do jakiego usera należą. Sprawdzimy w czym jest problem. Zaznaczcie proszę w zgłoszeniu, że dane które przesyłacie są potrzebne do ticketa numer 1878 na GitHub-ie.

Maczuga commented 5 years ago

@PawelTaberski poszło, zgłoszenie 05821072

PawelTaberski commented 5 years ago

Dzięki sprawdziłem i rzeczywiście jest jakiś błąd sprawę już zgłosiłem do rozwiązania z wysokim priorytetem.

aktywnitu commented 5 years ago

Czyli jednak nie trzeba było dogadywać się z InPostem.

ghost commented 5 years ago

Przypominam o tym że to jest niewystarczające, w przypadku płatności za pobraniem PaymentId = 0, więc nie da się zmapować. Potrzeba jest mapowania stareTransactionID = nowePaymentId @PrzemyslawLukanowski @MartaNowaczyk

PawelTaberski commented 5 years ago

@SebastianOzdoba Zweryfikowałem jeszcze i już teraz wysyłamy payment id w przypadku wybrania płatności za pobraniem. Czy w jakimś wypadku go nie otrzymałeś, mógłbyś podać jakiś przykład. Jeśli tak, to podeślij nam go przez formularz kontaktowy i zaznacz, że dane są potrzebne do zgłoszenia numer 1878 na GitHub-ie. Sprawdzimy to.

ghost commented 5 years ago

Byśmy się dobrze zrozumieli. Mówię o WebAPI, chcąc przejść płynnie z transakcjami międy webAPI a restAPI i by nie duplikować ich w momencie przepięcia aplikacji potrzebujemy mapowania WEBAPI.TransactionID = restAPI.Id Zgodnie z dokumentacją restAPI jest to "id": "ffc396b0-9584-11e8-8d53-07c966f77738", -- identyfikator zamówienia

lub aby RestAPI zwracało przez pewnien czas WEBAPI.TransactionID Wysłałem dane przez formularz, ale nie są potrzebne

PawelTaberski commented 5 years ago

Powiedz mi bo się pogubiłem przy pomocy zasobu GET /payments/payment-id-mappings możesz zamienić transactionId na paymentId a ten następnie użyć w GET /order/checkout-forms?payment.id={payment.id}. Numer płatności jest zarówno przy pobraniowych jak i płatnych z góry. Kiedy dokładnie brakuje Tobie danych?

ghost commented 5 years ago

To nadal nie rozwiązuje problemu migracji WebAPI -> RestAPI

Mam aplikację gdzie transakcje są po WebAPI i zapisujemy te dane u siebie w lokalnej bazie. Do godziny przykładowo 10 działa po WebAPI, następnie o godzinie 10:01 przestawiam się na RestAPI. Teraz pobierając dane o transakacjach z RestAPI dostanę te same dane, które jeszcze minutę temu pobrałem w WebAPI, a że te dane posiadam już u siebie to chcę prosto sprawdzić czy mam dodać tą transakcję czy może nie bo ją pobrałem jeszcze przez WebAPI. Zatem w restAPI powinno znaleźć się webAPI.TransactionId lub powinno być mapowanie webAPI.TransactionId = restAPI.Id Tak bym mógł zapewnić ciągłość działania aplikacji i nie martwić się że będziemy mieć problem z duplikatami w danych i nie robić jakiś protez w działaniu

PawelTaberski commented 5 years ago

Rozumiem, że mapowanie nie zwraca wprost z transactionId numeru checkout-form, ale w dwóch krokach możesz otrzymać te dane. Natomiast w drugą stronę wystarczy, że z checkout-form-a skorzystasz z paymentId i zmapujesz go na transactionId.

ghost commented 5 years ago

@PawelTaberski dlaczego w dwóch zamiast w jednym, po co komplikujecie życie na czas migracji, ten kod będzie potrzebny przez max 30 dni. Wymagacie użycia armaty na wróbla.

ghost commented 5 years ago

Zrobiłem tak jak pisałeś, efekt = brak danych Przykład:

curl -X GET \ 'https://api.allegro.pl.allegrosandbox.pl/order/checkout-forms?payment.id=dc51bbf2-7d3a-11e9-9b83-e3b76621973c' \ -H 'accept: application/vnd.allegro.beta.v1+json' \ -H 'authorization: Bearer ' \ -H 'cache-control: no-cache'

trace-id →2e9a8bbb6780766c

{ "checkoutForms": [], "count": 0, "totalCount": 0 }

PawelTaberski commented 5 years ago

Jesteś pewny, że masz token na sprzedawcę, którego dotyczy ta sprzedaż?

Maczuga commented 5 years ago

@PawelTaberski jak tam z tym priorytetowym zgłoszeniem? 16 dni minęło, metoda dalej nie działa jak powinna.

ghost commented 5 years ago

@PawelTaberski tak, to jest nasze konto na sandbox :)

ghost commented 5 years ago

@PawelTaberski wysyłam więcej info

Przykładowa transakcja wyciągnięta z api { "id": "30be43c2-724b-11e9-b938-753833226f24", "messageToSeller": "paczka w ruchu", "buyer": { "id": "43955776", "email": "XXXXXXXXXXXX@user.allegrogroup.pl", "login": "comarchesklep", "guest": false, "personalIdentity": null, "phoneNumber": "+48 12 687 70 00" }, "payment": { "id": "5acbcc52-724b-11e9-8d0c-b7aee34a5568", "type": "ONLINE", "provider": "PAYU", "finishedAt": "2019-05-09T11:13:41.166Z", "paidAmount": { "amount": "37.00", "currency": "PLN" } }, "status": "READY_FOR_PROCESSING", "delivery": { "address": { "firstName": "Firma", "lastName": "B", "street": "aaa, 12", "city": "XXXXXXXXXXXX", "zipCode": "XXXXX", "countryCode": "PL", "companyName": null, "phoneNumber": "999999999" }, "method": { "id": "b715fac1-8ec2-4f5c-8fdf-0f9cec9085ad", "name": "Paczka w RUCHu" }, "pickupPoint": { "id": "152231", "name": "PACZKA w RUCHu: KT-152231-81-12", "description": null, "address": { "street": "XXXXX", "zipCode": "3XXX", "city": "XXXXXXXXX" } }, "cost": { "amount": "12.00", "currency": "PLN" }, "smart": false }, "invoice": { "required": false, "address": null }, "lineItems": [ { "id": "30be43c0-724b-11e9-b938-753833226f24", "offer": { "id": "6206314790", "name": "Kiwi: soczyste i treściwe", "external": { "id": "4" } }, "quantity": 1, "originalPrice": { "amount": "25.00", "currency": "PLN" }, "price": { "amount": "25.00", "currency": "PLN" }, "selectedAdditionalServices": [], "boughtAt": "2019-05-09T11:13:19.559Z" } ], "surcharges": [], "discounts": [], "summary": { "totalToPay": { "amount": "37.00", "currency": "PLN" } } }

I to co zwraca metoda

curl -X GET \ 'https://api.allegro.pl.allegrosandbox.pl/order/checkout-forms?payment.id=5acbcc52-724b-11e9-8d0c-b7aee34a5568' \ -H 'accept: application/vnd.allegro.beta.v1+json' \ -H 'authorization: Bearer ' \ -H 'cache-control: no-cache'

trace-id →b5e4d84e519856bb

{ "checkoutForms": [], "count": 0, "totalCount": 0 }

Maczuga commented 5 years ago

@SebastianOzdoba @PawelTaberski również potwierdzam, że na produkcyjnym checkout-forms przy pobieraniu przez payment.id zwraca takie puste response (struktura z pustymi danymi).

ID tych transakcji (dla których da się pobrać paymentId, ale nie da się pobrać checkout-forms na jego podstawie) są razem z pozostałymi, dla których nie da się pobrać kompletnie paymentId w zgłoszeniu https://github.com/allegro/allegro-api/issues/1878#issuecomment-507339061

Jak trzeba to mogę w kolejnym zgłoszeniu podesłać 2 oddzielne listy:

  1. ID transakcji, dla których nie można pobrać paymentId
  2. paymentId, które zostały pobrane na podstawie id transakcji, ale checkout-forms jest pusty.

Na chwilę obecną - na ~1000 transakcji - dla 151 nie można pobrać wcale paymentId, dla 33 nie można pobrać checkout-forms (na podstawie zwróconego paymentId). Dla 6 dostałem błąd 504, ale to już inna sprawa.

PawelTaberski commented 5 years ago

@Maczuga Zespół pracuje nad rozwiązaniem tego problemu, odnośnie braków przy pobieraniu przez payment.id podeślij koniecznie przez formularz kontaktowy numery tych payment.id i oferty jakich dotyczą sprawdzimy to. Zaznacz, że dane są potrzebne do zgłoszenia na GitHub-ie numer 1878. @SebastianOzdoba Zgłosiłem ten problem do odpowiedniego zespołu, dzięki za dane.

krsvsh commented 5 years ago

wiem, że niewiele wniesie to do dyskusji ale dlaczego nie możecie dodać ID z WebAPI do checkout-forms? naprawde ułatwiło by to życie całkiem sporej ilości osób... ja korzystam z RESTa a inna firma dostarcza nam dane, które pobiera od Was z WebAPI... teraz muszę bezsensownie kombinować klepiąc pusty kod, kótry za miesiąc wywalę do kosza... czy jest jakaś racjonalna przyczyna braku umieszczenia ID w checkout-forms

Maczuga commented 5 years ago

@PawelTaberski podesłałem paymentId, które przy odpytywaniu checkout-forms zwracają response z pustymi danymi - zgłoszenie 05972821.

PawelTaberski commented 5 years ago

@Maczuga sprawdziłem i wszystkie przypadki jakie podesłałeś miały anulowaną płatność, dlatego nie możesz pobrać danych. @krsvsh Spowodowane jest to uwarunkowaniami technicznymi numery pochodzą z różnych usług.

PawelTaberski commented 5 years ago

@SebastianOzdoba Otrzymałem informacje, że po payment.id można wyszukiwać tylko te checkout formy, które zostały zmodyfikowane (np. zmiana statusu płatności) po 10.05.2019 po godzinie 16:30.

Goral64 commented 5 years ago

@Maczuga sprawdziłem i wszystkie przypadki jakie podesłałeś miały anulowaną płatność, dlatego nie możesz pobrać danych.

To trochę słabe. Robię mapowanie (WebAPI)dealTransactionId na (RestAPI)paymentId { "paymentId": "3f7a0472-a95b-11e9-8a39-75f03b6a8167", "transactionId": "1048131825" } Następnie wyszukuję checkoutForm po paymentId i dostaję jeden checkoutForm o id 1d2087a2-a95b-11e9-acde-9777fb156c5c A potem zdziwko, bo /order/checkout-forms/1d2087a2-a95b-11e9-acde-9777fb156c5c zwraca mi {"errors": [{ "code": "CHECKOUT_FORM_NOT_FOUND", "message": "checkout form not found", "details": null, "path": "/order/checkout-forms/1d2087a0-a95b-11e9-acde-9777fb156c5c", "userMessage": null }]}

Chyba nie o to chodzi w migracji z WebAPI na RestAPI żeby jeden zasób zwracał dane, a drugi udawał że ich nie ma?

Podobnie (nie)działa wykorzystanie mapowania dealId<->lineItemId

A może problem jest w tym, że filtrowanie checkout-forms i orders pod kątem ich statusów i statusów płatności powinniście zostawić odbiorcom danych?

PawelTaberski commented 5 years ago

W przypadku: "transactionId": "1048131825" system nie zwraca danych bo płatność była anulowana. Powinien Pan skorzystać z najnowszego transactionId.