I am working on verifone payment terminal.i am stuck in self assessment 2.04 where i need to login and then proceed previous transaction after the internet connection lost.i contact there team and they provide the following solution but it is not working for me.please check and give your sugestions:
"If the connection is lost, the POS will receive a PaymentCompletedEvent with PaymentCompletedEvent.getStatus() equaling StatusCode.DEVICE_CONNECTION_LOST. In this case, the only thing to do is to call PaymentSdk.tearDown() and then initialize to recover the connection. To obtain the last transaction result, create a TransactionQuery object, use TransactionQuery.setQueryingLastTransaction(true) to mark it as recovering the information about the most recent payment, and then examine the information returned in the TransactionQueryEvent. The payment’s authorization result will be IN_PROGRESS if it is still processing, it can be cancelled as Cancel the Transaction, or it will contain the actual result."
Related
I tried to create a profile in Data Scan, a PRE-OFFERING in Dataplex, but even having the Admin permisssions, an error occured making it impossible to test data scan. I submitted a feedback but I still have no answer about it. Can anyone help?
I would like to test data scan in a client that has a data-lake active.
are few days that we are experiencing trouble with revolut api.
We use that library: https://github.com/useme-com/revolut-python
Now when we try to retrive a list of transactions we receive:
root## python3 transactions.py
HTTP 400 for https://b2b.revolut.com/api/1.0/transactions: Duplicate key User#XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX (attempted merging values XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX and YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYY)
The code is pretty straightforward, to debug basically:
[...]
# Enable Session
session = RenewableSession(refreshtoken,clientid,jwttoken)
# Create API Client
revolut = Client(session)
# Transactions Display
for transaction in revolut.transactions():
print(transaction)
[...]
The same code, from our side, worked until 3 days ago, without errors.
Any ideas on what's going on?
Possible that exist a failure from revolut side?
They are not responding on this (already opened a ticket about).
ty
I got this issue while using a high count param
https://b2b.revolut.com/api/1.0/transactions?count=1000
Reducing count to 100 or 200 made me get a good response. I think Revolut has some issues when sending API response that includes a very old historical transaction due to changes in data structure/merging etc at their end
I am dealing with a Shopware6 plugin for a payment gateway. I have to handle the change of the state for the order transaction.
In one of my case, I would like to prevent the change of state in Refunded for an order transaction when I am trying to perform a refund on a payment provider and I receive an error.
I found this method \Shopware\Core\System\StateMachine\StateMachineRegistry::transition
public function transition(Transition $transition, Context $context): StateMachineStateCollection
{
...
$repository->upsert($data, $context);
...
$this->eventDispatcher->dispatch(new StateMachineTransitionEvent(...));
...
$this->eventDispatcher->dispatch(...);
...
$this->eventDispatcher->dispatch(...);
...
}
where more than one event is dispatched, but all of them after the upsert.
Even if I raise an Exception in a subscriber of those events, the upsert already updated the db table and I have no chance to revert it, especially because the Refunded state is a no exit state.
How can I prevent or revert the upsert?
You can revert the upsert. For that you would need to write a new transition to the database.
The table you are looking for is state_machine_transition and how the data is written to that table can be found under platform/src/Core/Migration/Migration1536233560BasicData.php#1078. You will need to do this in your plugin migration.
Then you could transition the state again after it was changed to your edgecase.
What is the preferred way to validate requested DICOM connection against a list of known hosts?
I can connect to the EVT_CONN_OPEN event. But in that, the event.assoc.requestor.info.ae_title element is always empty (b'').
I see from a TCP network analysis, that the name is transmitted. So, where is it?
What is the right way to validate the requesting host?
You could try using EVT_REQUESTED instead, it gets triggered after an association request is received/sent and the AE title information should be available at that point. Unfortunately EVT_CONN_OPEN is triggered on TCP connection which occurs prior to the association request.
If you don't like the host's details you can use the handler to send an association rejection message using event.assoc.acse.send_reject() or abort with event.assoc.abort().
If you're only interested in validating against the AE title you can use the AE.require_calling_aet property to restrict associations to those with matching AE titles.
For the benefit of anyone else looking this up, the correct stage to look this up is in the EVT_REQUESTED event. However you will likely find the details aren't filled in (they are populated AFTER the handler has been called).
So if you want to locate the callers AE in EVT_REQUESTED, you need to locate the A_ASSOCIATE primitive and read them from there. So for example in your handler you can do this to reject remotes:
def handle_request(event):
req_title = event.assoc.requestor.primitive.calling_ae_title.decode('ascii')
if req_title != 'MyAET':
event.assoc.acse.send_reject(0x01, 0x01, 0x03)
return
At least for 1.5.7.
I successfully submit an equity order to E*Trade using https://etws.etrade.com/order/rest/placeequityorder:
<PlaceEquityOrder xmlns="http://order.etws.etrade.com">
<EquityOrderRequest>
<clientOrderId>1507910303000001</clientOrderId>
<accountId>xxx</accountId>
<quantity>1</quantity>
<orderAction>BUY</orderAction>
<priceType>LIMIT</priceType>
<marketSession>REGULAR</marketSession>
<orderTerm>GOOD_FOR_DAY</orderTerm>
<symbol>TEUM</symbol>
<limitPrice>0.6</limitPrice>
</EquityOrderRequest>
</PlaceEquityOrder>
The order is confirmed ok by E*Trade:
<PlaceEquityOrderResponse>
<equityOrderResponse>
<accountId>xxx</accountId>
<allOrNone>false</allOrNone>
<estimatedCommission>6.95</estimatedCommission>
<estimatedTotalAmount>7.55</estimatedTotalAmount>
<messageList>
<message>
<msgDesc>Your order was successfully entered during market hours.</msgDesc>
<msgCode>1026</msgCode>
</message>
</messageList>
<orderNum>10</orderNum>
<orderTime>1507924703308</orderTime>
<quantity>1</quantity>
<reserveOrder>false</reserveOrder>
<reserveQuantity>0</reserveQuantity>
<orderTerm>GOOD_FOR_DAY</orderTerm>
<limitPrice>0.6</limitPrice>
<stopPrice>0</stopPrice>
<symbolDesc>PARETEUM CORP COM NEW</symbolDesc>
<symbol>TEUM</symbol>
<orderAction>BUY</orderAction>
<priceType>LIMIT</priceType>
</equityOrderResponse>
</PlaceEquityOrderResponse>
Then I try to update the limit price with https://etws.etrade.com/order/rest/placechangeequityorder:
<placeChangeEquityOrder xmlns="http://order.etws.etrade.com">
<changeEquityOrderRequest>
<orderNum>10</orderNum>
<clientOrderId>1507910303000001</clientOrderId>
<accountId>xxx</accountId>
<quantity>1</quantity>
<orderAction>BUY</orderAction>
<priceType>LIMIT</priceType>
<marketSession>REGULAR</marketSession>
<orderTerm>GOOD_FOR_DAY</orderTerm>
<symbol>TEUM</symbol>
<limitPrice>0.61</limitPrice>
</changeEquityOrderRequest>
</placeChangeEquityOrder>
But the change is rejected with
> <Error><ErrorCode>1028</ErrorCode><ErrorMessage>You have an existing
> open order for this security on the same side of the market. If you
> did not intend to place a second order for this security, please click
> Cancel Order ; otherwise, click Trade to
> proceed.</ErrorMessage></Error> ---> System.Net.WebException: The
> remote server returned an error: (400) Bad Request.
I tried including and not including clientOrderId, it made no difference. I'm going nuts because the same code worked fine once earlier in the day, then it never worked again.
If you are able to submit changes to orders using the ETrade API, please let me know. ETrade API forum seems to have disappeared :(
One needs to submit a new clientOrderId with every change request. I had assumed that one was supposed to keep sending the original clientOrderId (the one used when first submitting the order).