I am using Outlook 365. When I forward received emails, I want all text after a particular string ('regards' in the example below) to be deleted.
For example, I receive the following email which I want to forward:
From: Sender Gmail sender#gmail.com
Sent: Saturday, 18 February, 2023 02:58
To: Receiver receiver#gmail.com
Subject: DTP Query
Hello Receiver,
Hope you are doing well.
Please review the project and let me know the cost and turnaround time.
Best regards
ABC Enterprises
New Delhi, India
abc#gmail.com
I want the header removed:
From: Sender Gmail sender#gmail.com
Sent: Saturday, 18 February, 2023 02:58
To: Receiver receiver#gmail.com
Subject: DTP Query
I want to retain:
Hello Receiver,
Hope you are doing well.
Please review the project and let me know the cost and turnaround time.
Best regards
And all information after regards to be removed:
ABC Enterprises
New Delhi, India
abc#gmail.com
Is there a way to do this?
Dhiraj Aggarwal
New Delhi, India
I am not a technical guy, so didn't try anything.
In sandbox mode i am able to store credit card numbers, however when i retrieve it the card number is masked IE "xxxxxxxxxxxx1111".
The documentation states that it should be a numeric string.
Is this how it is supposed to work or does it just do this in the sandbox?
This is correct functionality. The full card number is hidden in the response, so the above information is accurate.
You'll find the information in the developer's page under Vaulted Credit Cards:
"The credit card number. Valid value is a string of numeric characters with no spaces or punctuation. Must conform to modulo and the length required by its credit card type. Redacted in responses."
https://developer.paypal.com/docs/api/vault/#credit-card_create_response
I have built a store on PrestaShop 1.6 that works in an unsupported by PayPal currency - BGN which at the moment has an exchange rate
1xEUR = 1.96 BGN
However, when a purchase is made the PayPal module sends the ex. 16,50 BGN as 8.00 EUR which should be 8.44 EUR.
Any idea what is going on and how can I fix this?
I found out that the problem was in the currency decimal sign. The platform was set to use no digits after the decimal sign so it was flooring the sum down.
If you have this problem go to Localization->Currencies->choose you currency-> turn on Decimals. That should be made to all currencies in order to work.
We have an issue with our PayPal Express Checkout integration. We see an error coming back from DoExpressCheckout with code 10004 saying "Transaction refused because of an invalid argument. See additional error messages for details." But the response contains no additional error messages.
This occurs randomly with our integration. It started approximately one month ago and has happened 70 times vs 1430 successful transactions.
It appears to be random. Not tied to any specific amounts, browser type, time of transaction etc. One user could have several failures then try again with the same token and have it go through. Some users have come back 10 minutes later or change browser and it works. Most give up.
I'd appreciate any suggestions, is there a way to retrieve any more debug for this error?
SetExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=112
METHOD=SetExpressCheckout
ALLOWNOTE=0
ADDROVERRIDE=1
PAYMENTREQUEST_0_SHIPTONAME=Mr X
PAYMENTREQUEST_0_SHIPTOSTREET=Test St
PAYMENTREQUEST_0_SHIPTOSTREET2=
PAYMENTREQUEST_0_SHIPTOCITY=City
PAYMENTREQUEST_0_SHIPTOSTATE=State
PAYMENTREQUEST_0_SHIPTOZIP=5000
PAYMENTREQUEST_0_SHIPTOCOUNTRYCODE=AU
PAYMENTREQUEST_0_SHIPTOPHONENUM=8888888888
RETURNURL=URLA
CANCELURL=URLB
PAYMENTREQUEST_0_PAYMENTACTION=Authorization
PAYMENTREQUEST_0_CURRENCYCODE=AUD
PAYMENTREQUEST_0_AMT=20.9
L_PAYMENTREQUEST_0_NAME0=DOOM PATROL VOL 6 #3
L_PAYMENTREQUEST_0_AMT0=7.95
L_PAYMENTREQUEST_0_NUMBER0=SEP160206
L_PAYMENTREQUEST_0_QTY0=1
L_PAYMENTREQUEST_0_CURRENCYCODE0=AUD
L_PAYMENTREQUEST_0_NAME1=MOTHER PANIC #1
L_PAYMENTREQUEST_0_AMT1=7.95
L_PAYMENTREQUEST_0_NUMBER1=SEP160201
L_PAYMENTREQUEST_0_QTY1=1
L_PAYMENTREQUEST_0_CURRENCYCODE1=AUD
L_PAYMENTREQUEST_0_NAME2=Regular Post (cannot be tracked)
L_PAYMENTREQUEST_0_AMT2=5
L_PAYMENTREQUEST_0_NUMBER2=Freight
L_PAYMENTREQUEST_0_QTY2=1
L_PAYMENTREQUEST_0_CURRENCYCODE2=AUD
GetExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=2.3
TOKEN=EC-5DX46556HG972093T
METHOD=GetExpressCheckoutDetails
DoExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=2.3
PAYMENTACTION=Authorization
PAYERID=XXX
TOKEN=EC-5DX46556HG972093T
AMT=20.9
CURRENCYCODE=AUD
METHOD=DoExpressCheckoutPayment
PayPal returns:
TOKEN=EC-5DX46556HG972093T
TIMESTAMP=2016-11-23T10:53:35Z
CORRELATIONID=XXX
ACK=Failure
VERSION=2.3
BUILD=000000
L_ERRORCODE0=10004
L_SHORTMESSAGE0=Internal Error
L_LONGMESSAGE0=Transaction refused because of an invalid argument. See additional error messages for details.
L_SEVERITYCODE0=Error
Error was on PayPals side. If you have the same issue just log a support ticket and magic will happen.
I'm having trouble with the Chained Payments API, still in development.
Speaking for the sandbox: I've read that, for some reason, the PayKey (the unique identifier Paypal creates for the transaction), is not passed back to the transaction. And certainly, in my testing, I get most the data back (like the buyer's email address, name, address information) but I do not get the paykey back.
This field is not just blank, it's not present at all. I'm doing the most basic loop over the form scope and writing the results to a file (obviously I won't be doing something this rudimentary in production, this was just to understand what data I was getting).
So I thought I'd pass my own unique identifier, store that in the database, and then pass that through the custom variable. This, (the custom field) oddly, comes back blank every time.
Finally I thought I'd just pass it as part of the url of the IpnNotificationUrl like receipt.cfm?myKey=SOMEVERYRANDOMLYGENERATEDKEYHERE but when I pass IpnNotificationUrl, the specified url is not pinged, whether or not I have a separate IPN Notification URL setup in my sandbox account. The URL specified in the account is properly pinged each time.
Both files are identical except that they write to differently named text files. I'm not getting an error off either file.
<cfoutput><cfsavecontent variable="buildfile">--- Break ---
<cfloop list="#structkeylist(form)#" index="i">
#i#: #form[i]#
</cfloop>
</cfsavecontent></cfoutput>
<cffile file="#expandpath(".")#\dump_new.txt" action="write" output="#buildfile#" />
I need to be able to create a key and pass through Paypal or Paypal needs to pass back.
For what it's worth, this is my invocation from Paypal's SDK on GitHub
<cfinvoke component="svc.adaptivepayments" method="payRequest" returnvariable="response">
<cfinvokeargument name="returnURL" value="#request.serverURL#/success.cfm">
<cfinvokeargument name="cancelURL" value="#request.serverURL#/cancel.cfm">
<cfinvokeargument name="ipnNotificationUrl" value="http://myurl/taction/pp_rect2.cfm">
<cfinvokeargument name="senderEmail" value="">
<cfinvokeargument name="custom" value="test data">
<cfinvokeargument name="receiverAmount" value="#ArrayToList(pp_amounts)#">
<cfinvokeargument name="receiverEmail" value="#ArrayToList(pp_emails)#">
<cfinvokeargument name="receiverPrimary" value="true,false,false,false,false,false">
<cfinvokeargument name="feesPayer" value="PRIMARYRECEIVER">
<cfinvokeargument name="receiverPaymentType" value="DIGITALGOODS,DIGITALGOODS,DIGITALGOODS,DIGITALGOODS,DIGITALGOODS,DIGITALGOODS">
<cfinvokeargument name="actionType" value="PAY">
<cfinvokeargument name="currencyCode" value="USD">
</cfinvoke>
Edit: For clarification, Paykey comes back from this service, it's how I generate the link to send the user to paypal. Paykey simply doesn't get passed to my IPN, though other transaction data does. I removed certain information. And I've double checked, none of this information is the paykey or is available at time of paykey creation (so there's no unique identifier on both ends)
--- Break ---
payer_email: redacted
charset: windows-1252
item_name:
payment_gross: 10.00
payer_id: A62WKW8N3YDYU
transaction_subject:
item_number:
payment_status: Completed
payment_fee: 0.55
notify_version: 3.8
verify_sign: A.CSYz4u5IILQm5wM0J0JbJiIcEuAHODNEgw.2k7ZMYT31eXFO6G0R1o
mc_currency: USD
quantity: 0
residence_country: US
tax: 0.00
first_name: John
receiver_email: redacted
last_name: Blow
mc_fee: 0.55
ipn_track_id: dd4151b653ead
payer_status: verified
custom:
fieldnames: payer_email,charset,item_name,payment_gross,payer_id,transaction_subject,
item_number,payment_status,payment_fee,notify_version,verify_sign,
mc_currency,quantity,residence_country,tax,first_name,receiver_email,
last_name,mc_fee,ipn_track_id,payer_status,custom,mc_gross,test_ipn,
business,txn_id,receiver_id,txn_type,payment_type,payment_date,protection_eligibility
mc_gross: 10.00
test_ipn: 1
business: redacted
txn_id: 71N09598H1922352W
receiver_id: VBETUFDEQL5BC
txn_type: web_accept
payment_type: instant
payment_date: 12:53:10 Nov 04, 2014 PST
protection_eligibility: Ineligible
I think you're getting lost in the fact that Adaptive Payments transactions actually have separate IPN's for the app and for the receiver. In cases where you're acting as both, you would get 2 separate IPN's.
What you've included here is the receiver/transaction specific IPN. That would not include a PayKey, but instead, a transaction ID, like you're getting. You'll notice there is no PayKey parameter at all (as opposed to it being included, but blank, like you originally stated.)
If you want to process app specific data, including the PayKey, you'll need do that from within the app specific IPN, which is what I linked you to for my sample. You'll notice the parameters it includes are much different than what you're getting here.
In my sample, I was indeed both the app owner and the receiver of the transaction, so I got 2 IPN's at the same time, but of course my IPN script is configured to handle them accordingly.
So again, I had an app specific IPN, which includes app specific data including the PayKey. Then I also got a separate transaction specific IPN, which includes data like you're showing here, but does not include a PayKey.
You need to make sure you're handling both correctly. The IPNNotificationURL parameter in your Pay request would trigger the app specific IPN, where-as the IPN config in the receiver account would trigger the transaction specific IPN.
I see that you are including a value for IPNNotificationURL in your request, but the data you're getting is not that. You need to check your web server logs because it seems like that one must be failing for some reason, but then the other is hitting and succeeding.