Very confused by the crowd of paypal-APIs, I wonder if I just can fetch the transactions (in and out) somehow, just like I would it export to csv via webinterface.
Here I am:
REST-API seems not working for "non-rest-transactions" Payment.all.size == 0 paypal-rest-api-list-payments-returns-no-entries
Merchant-API does not allow detailed info for specific transactions.
https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/GetTransactionDetails_API_Operation_SOAP/ says:
Note The details for some kinds of transactions cannot be retrieved
with GetTransactionDetails. You cannot obtain details of bank transfer
withdrawals, for example.
I recieved a view transactions via transactionSearch. Took the transactionId from one of the transactions.
api.get_transaction_details(:transaction_id => transaction_id>)
=> #<PayPal::SDK::Merchant::DataTypes::GetTransactionDetailsResponseType:0x007fd3c0f1f8d8
#Ack="Failure",
#Errors=[#<PayPal::SDK::Merchant::DataTypes::ErrorType:0x007fd3c0f379d8
#ShortMessage="Invalid transaction type",
#LongMessage="You can not get the details for this type of transaction",
#ErrorCode="10004",
#SeverityCode="Error">]
Adaptive-API (PaymentDetails with transactionID) throws an "internal error 520002" with no details. (And I found no specification if it could fetch all transactions)
Ok, it's Paypal. But there must be a simple solution they forgot to mention. (?!) Or what did I miss?
Thanks and regards, Phil
I don't know where you're seeing info that the merchant API won't provide details about transactions, but that's simply wrong.
You you can use TransactionSearch to obtain a list of transactions within a given time period, and then you can loop through those results and use GetTransactionDetails to obtain the details for each individual transaction.
Related
https://explorer.near.org/blocks/99qdUGNmGMMQQdKGmgA7Lf6PjaXAHgVVy53DLHJZpcbb
Block - 35866073 has 5 transactions
ChunkHash - GwMUrTgEfqEaV9s8ngvqUn9c4hi4G8Ywpggoy4VDwnok
5 transactionHshses
TransactionHash 2 - AMDbiQUJx2Dd9FfbaYYbNj2D6T6xPJMHgWCZ4RTrN1UU
Transfer from comchien.near to 85a577d5db02df7830c8ad3db76ca6a90dee6f176c8478eb12dbf30d8d2d54ee - 5.58572
TransactionFee - ? there is some transaction Fee shown in explorer but in Json structure i dont see the transaction fee , can you plese help how can i get the transaction fee
TransactionHash 2- 6Beo8SFyjPjjtFnT3b2aEGDHgPY9HxGZ17vWvpSN733c
I can see storage_deposit , near_deposit and ft_transfer_call. Does all the amount gets transferred to wrap.near. And same transaction Fees is missing in json struture.
Transactions in NEAR are just inputs. To see the outputs (execution outcomes), you need to query transaction details using tx RPC to see transaction_outcome -> outcome -> tokens_burned field. That is the transaction initial processing fee. Next, you need to fetch receipt execution outcomes (well, it is right there in the tx RPC response) and sum all the receipts_outcome -> outcome -> tokens_burned. That is exactly what NEAR Explorer does.
You also could find this doc useful where I explain all balance changes there.
The full text of the message is :
{code: 1012, message: "Transaction is temporarily banned"}
This would indicate that the transaction is held somewhere in Substrate Runtime mempool or something of that nature, but it is not entirely clear what possible causes can trigger this, and what the eventual outcome might be.
For example,
1) is it that too many transactions have been sent from a given account, IP address or other? Has some threshold been reached?
2) is the transaction actually invalid, or not?
3) The use of the word "temporary" suggests a delay in processing, not an outright rejection of the transaction. Therefore does this suggest that the transaction is valid, but delayed? If so, for how long?
The comments in the substrate runtime core/rpc/src/author/errors.rs and core/transaction-pool/graph/src/errors.rs is no clearer about what is the outcome.
In front of the mempool, exists a transaction blacklist, which can trigger this error. Specifically, this error means that a transaction with the same hash was either:
Part of recently mined block
Detected as invalid during block production and removed from the pool.
Additionally, this error can occur when:
The transaction reaches it's longevity, i.e. is not mined for TransactionValidation::longevity blocks after being imported to the pool.
By default longevity is set to u64::max so this normally should not be the problem.
In any case -ltxpool=log should reveal more details around this error.
A transaction is only temporarily banned because it will be removed from the blacklist when either:
30 minutes pass
There are more than 4,000 transactions on the blacklist
Check out core/transaction-pool/graph/src/rotator.rs.
We have been implementing an instant message service and want to use HBEASE to store message history (and using redis to caching ongoing conversation). The incoming message for a user looks like
Userid (to whom)
time
message body (combined with from, message body ....)
Regarding Schema design:
Option A: one message per row
Row key: md5(userid) + timesample
column/valye: null / message
Option B: one user per row
Row key: md5(userid)
column/valye: time / message
could you help me to figure out pro and cont? thanks
chatting type include: peer-2-peer, group chating
As far as I know Facebook has done a great job on message system use hbase; Maybe these links will help you:http://www.slideshare.net/brizzzdotcom/facebook-messages-hbase
http://sites.computer.org/debull/A12june/facebook.pdf
I'm trying to read the data off a contactless Visa Paywave card.
For the Paywave, I have to submit a SELECT using PPSE (2PAY.SYS.DDF01) instead of PSE (1PAY.SYS.DDF01).
The EMV book 1, section 11.3.4, table 43 only describes how to interpret the response for a successful SELECT command using PSE. Does anyone know or can refer me to a source that shows how to process the data returned from a successful SELECT command using PPSE?
Here's my request APDU:
00A404000e325041592e5359532e444446303100
Here's the response:
6F2F840E325041592E5359532E4444463031A51DBF0C1A61184F07A0000000031010500A564953412044454249548701019000
I understand tag 84, tag 85, tag BF0C from the response. According to the examples for reading PSE, I should be able to just send GET PROCESSION OPTIONS (to get the AIP and AFL) with PDOL = null after this successful response as follows: 80A80000830000.
But request 80A80000830000 returns error code 6985 - Command not allowed; conditions of use not satisfied.
I also tried reading all the files after successfully selecting the PPSE by traversing through every single SFI (0-30) and every single record (0-16) of each SFI. Yes, I also did the 3 bit shift and bitwise-OR the SFI with 0x4. But I got no data.
I'm stuck, any help that would point me into getting some info from my Paywave card would be appreciated!
Have you tried this tool from EMVLAB http://www.emvlab.org/emvtags/
Using that tool,
http://www.emvlab.org/tlvutils/?data=6F2F840E325041592E5359532E4444463031A51DBF0C1A61184F07A0000000031010500A564953412044454249548701019000
2PAY.SYS.DDF01 is for contactless (e.g. NFC ) cards, while 1PAY.SYS.DDF01 is for contact cards.
After successfully (SW1 SW2 = 90 00) reading a PSE, you should only search for the SFI (tag 88) which is a mandatory field in the FCI template returned.
With the SFI as your start index, your would have to read the records starting from the start index until you get a 6A83 (RECORD_NOT_FOUND). E.g. if your SFI is 1, you would do a readRecord with record_number=1. That would probably be successful. Then you increament record_number to 2 and do readRecord again. The increament to 3 .... Repeat it until you get 6A83 as your status.
The records read would be ADFs (at least 1). Then your would have to compare the read ADF Names with what your terminal support and also based on the ASI (Application Selection Indicator). At the end you would have a list of possible ADFs (Candidate list)
All the above steps (1-3) are documented in chapter 12.3.2 Book1 v4.3 of the EMV spec.
You would have to make a final selection (Chapter 12.4 Book1)
Read the spec book 1 chapter 12.3 - 12.4 for all the detailed steps.
You seem to have the flow mixed up a bit, you want to:
Send 1PAY or 2PAY, it doesn't actually matter for all of the cards I've tested. This will return a list of the AIDs available on the card. Alternately you can just select an AID straight away if you know it's there but good practice would be to check first.
Get the list of AIDs returned in response to 1PAY/2PAY, in PayWave's case this will probably be A0000000031010 if you sent 2PAY but you may get more if you send 1PAY.
Select one of the AIDs sent back (or one you already know is on there).
Then loop through the SFIs and records sending the Read Records command to get the data.
You don't have to send Get Processing Options before sending the Read Records command even though that's now a normal transaction flow goes.
I think the information you're looking for is available from this VISA website. But only if you're a registered and/or licensed partner of VISA.
EDIT: Looking at the resulting TLV struct under BF0C:
tag=0xBF0C, length=0x1A
tag=0x61, length=0x18
tag=0x4F, length=0x07, value=0xA0000000031010 // looks like an AID to me
tag=0x50, length=0x0A, value="VISA DEBIT"
tag=0x87, length=0x01, value=0x01
I would guess that you need to first select A0000000031010 before getting the processing options.
I was selecting application 2PAY.SYS.DDF01. when I should have been selecting AID = 0xA0000000031010. It looks like there's no records under application 2PAY.SYS.DDF01.
But there was 1 record under application 0xA0000000031010. After I got this application, I performed a READ RECORD, and the first record gave me the PAN and all the credit card info I wanted.
Thanks everyone for chiming in.
For some reason order ID's (increment_id on sales_flat_order table) are not incrementing subsequently on my Magento 1.6.1. This is how it looks after a number of live orders placed:
increment_id created_at updated_at
100000001 2011-12-14 12:35:24 2011-12-14 12:35:25
100000002 2011-12-14 13:02:39 2011-12-14 13:02:39
100000003 2011-12-14 13:04:18 2011-12-14 13:04:18
100000004 2012-02-01 16:54:58 2012-02-01 16:54:58
100000005 2012-03-14 12:22:35 2012-03-14 12:22:35
100000006 2012-03-20 13:10:48 2012-03-20 13:10:48
100000011 2012-03-29 20:58:48 2012-03-29 20:58:48
100000012 2012-03-29 21:06:43 2012-03-29 21:06:43
100000013 2012-03-30 10:48:20 2012-03-30 10:48:21
100000014 2012-03-30 13:05:40 2012-03-30 13:05:41
100000015 2012-04-03 15:51:01 2012-04-03 15:51:02
100000016 2012-04-19 15:00:49 2012-04-19 15:00:50
100000017 2012-05-09 12:09:21 2012-05-09 12:09:22
100000019 2012-05-24 05:35:35 2012-05-24 05:35:36
100000020 2012-05-24 05:41:11 2012-05-24 05:41:12
100000008 2012-05-24 05:48:52 2012-05-24 05:48:53
My question is why is Magento jumping increments sometimes? And worse yet, in my example order with increment 100000008 goes after 100000020. Does someone know why this is happening and if there's a way to fix it?
This is normal, albeit understandably disconcerting.
When Magento enters the checkout process it 'reserves' an increment_id and places it on the quote (cart) object. You can see the code that gets an increment id at:
Mage_Eav_Model_Entity_Type::fetchNewIncrementId()
The last used ID for each store is stored in eav_entity_store. If a customer abandons their cart (ie the quote object) before completing the checkout process, the reserved increment_id will never show up on an order. You can see this effect sometimes in the order numbers as they come in on a busy store - occassionally a really old order id comes through in the day's orders from a customer that is checking out an old cart.
This behaviour exists to allow Magento to send payment gateways the final order id (increment_id), before the order is completed allowing the gateway to associate the order id with the order. If the customer abandons the payment process in the gateway, the order id is dead (or more correctly still attached to the quote).
You can see this happening in the PayPal express module at:
Mage_Paypal_Model_Express_Checkout::start()
which calls
Mage_Sales_Model_Quote::reserveOrderId()
If you want to find your 'missing' increment_ids, take a look in sales_flat_quote under the field reserved_order_id. You should see them attached to unconverted quote objects (carts).
This behaviour can create issues with some payment gateways; Moneris comes to mind. When you send Moneris' hosted paypage the same order id twice, it chokes and creates a cryptic error state for the customer. This condition occurs when the customer visits the hosted pay page, backs out and re-visits the page. Hence in some cases, it is necessary to re-generate the order id associated with the quote object programmatically.
I was facing the same issue but it was only when the server was hit with a huge amount of load. This issue occurs because the db goes into the lock state while converting quote into order. On further inspection, I found out that the issue was that it tried to write into sales_flat_order_grid table within transaction right after insert into sales_flat_order table. With concurrent queries it caused locking collisions. The real solution is to move stuff of sales_flat_order_grid out of the transaction.
The link helped me understand the issue
The patch resolved the issue for me.
You have to remove function _afterSave from the Mage_Sales_Model_Abstract and add
public function afterCommitCallback(){
if (!$this->getForceUpdateGridRecords()) {
$this->_getResource()->updateGridRecords($this->getId());
}
parent::afterCommitCallback();
}
Let me know if it solves the problem for you.
We have had this same issue multiple times over the past couple of months. Upon checking our payment service provider transaction list we see 1000's of low value (micro) transactions being declined due to potential fraud issues. My opinion is that a fraudster is trying to use our checkout process to probe the list of cards they have to find out what cards are valid and what cards are dead. I have reported it to action fraud, our web host and our payment provider.
In summary, my advise would be for you to check your PSP list of transactions for the same time period.
Good luck with it,
Brisc.